[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Is pmax alive?
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
> 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
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
Main Index |
Thread Index |