I also have no rights to change the code, I am just a bystander :).
lw instructions usually expand in to 2 load immediate instructions if a 
value could be calculated at compile time or $at is used if value is a 
memory location. $at not supposed to be used directly so it should not 
be a problem. My only concern was a $k1 register. I can see it is loaded 
later with some value so it is not a problem as well. It could become a 
proble though if someone decides to use k1 like it was properly loaded.

If branch is not taken k1 will endup containing the correct value and 
nothing should be corrupted. If branch is taken probably $at will 
contain part or whole of the address of Sysmap, k1 will contain no 
meaningful value. I am actually surprised that assembler would try to do 
what it does and not insert "nop" in the delay slot, but there is 
probably a reason for this.

I am new to NetBSD but as I hear it has a good design and code practices 
so my opinion as an outsider that warnings should be cleaned up :).

Thanks,
Alex


Eric Christopher wrote:
> On Fri, 2005-02-25 at 15:42 -0500, Paul Koning wrote:
> 
>>>>>>>"Martin" == Martin Husemann <martin@duskware.de> writes:
>>
>> Martin> On Fri, Feb 25, 2005 at 10:59:19AM -0800, Eric Christopher
>> Martin> wrote:
>> >> Most assuredly not.
>>
>> Martin> In this cases it looks harmless - the branch (if taken) will
>> Martin> ignore the incomplete work of the pseudo instruction anyway
>> Martin> (but I'm not realy good at mips assembly)
>>
>>I remember some cases like that -- where the NOP for the delay slot
>>was missing, so the warning was on an instruction needed for the "no
>>branch" case.  If so, the NOP should be added to clean up the code.
>>
>>If the instruction that's written for the delay slot really did belong
>>in the delay slot, then it is post definitely broken if it expands to
>>multiple instructions.
> 
> 
> Exactly.
> 
> Basically what's happening now is that you're corrupting some register
> with the execution of the branch delay slot if the branch is taken
> (likely $at, but I've not tried to assemble it and verify), and if the
> branch isn't taken you've just modified another register (probably k0)
> with the other half of the macro instruction.
> 
> -eric
> 
> 
> 
>