Re: Is pmax alive?

["Maciej W. Rozycki" <macro%linux-mips.org@localhost>]

On Mon, 13 Jun 2016, David Holland wrote:

>  >  If people agree on removing the `.set noreorder' directive (note that it 
>  > will affect all MIPS ports, not only pmax, though the change is supposed 
>  > to be functionally neutral, which can perhaps be verified with `objdump 
>  > -d'),
> 
> So the problem with that is that gas doesn't really fill in delay
> slots; only the original assembler written by the MIPS folks has ever
> really done much of that.

 Huh?  Great care has been taken over the years to make GAS handle delay 
slot filling and to the best of my knowledge it works very well.  I went 
through the pain myself to implement it for the microMIPS ISA a few years 
ago as well, even though there it's trickier due to variable instruction 
lengths and delay slot instruction size restrictions.

 So please file a bug report if you have a case where expected delay slot 
filling does not happen in GAS and otherwise please do not spread 
misleading information.

> Also after twenty years of bitrot I would not trust gas to get the
> delay slots for supervisor instructions right for mips-I. It might
> work, but it might not too.

 MIPS I ISA support has been maintained and is going to continue being as 
long as I am around.  Please give specific examples of what does not work.  

 Please note however that neither GAS nor any other MIPS assembler is 
intended to resolve implementation-specific COP0 hazards.

> My recommendation would be to scrape up whatever docs we can find and
> assemble a canonical table of nop and delay requirements, then write
> an analyzer tool to run on .o files to detect violations. This is not
> very hard (disassembling mips machine code is somewhat annoying but
> straightforward) and has the advantage of being robust and reasonably
> future-proof. And useful for anything that wants to run on mips.

 Sure, feel free to write it.

> The problem I've always had is getting authoritative information about
> the requirements.
> 
> That and (especially on early r3xxx and r4xxx models) some of them
> vary randomly from model to model.

 Only as far as COP0 hazards are concerned -- and these need to be taken 
care of in a limited number of places only, such as TLB exception 
handlers.

 Delay slots are however straightforward and are handled by the toolchain.  
If there's an odd bug causing it not to happen somewhere, then I want to 
hear about it.

 NB I think it's better to let GAS waste a delay slot with a NOP somewhere 
and lose a cycle due to a bug, than to miss a pipeline dependency in 
manually scheduled assembly code and make it produce an incorrect result 
or crash.

  Maciej