[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [f-cpu] snapshot QDCPOC+YGASM



On Thu, Aug 02, 2001 at 08:31:00PM +0200, Yann Guidon wrote:
[...]
> > I have no problems with making the opcode either the LSByte or the MSByte
> > of the instruction, but we should stick with little-endian because
> > it's the default for the load and store instructions (without the `e'
> > flag set).
> as written above, the LSU has different goals and constraints.
> OTOH, the instructions are in a unique format, so let's make it
> practical. I almost remember a debate about endianness and some people
> wanted to be able to figure the instructions from a hexdump.

I'm so used to Intel-style assembler that I really don't care about byte
order in hexdumps any more.

On the other hand, FC0 instructions are all 32 bits long and can
therefore be represented in dumps as 32-bit numbers.  In that case,
endianness doesn't matter at all.

> Since the little endianness was chosen, i think that it conditionned
> the current non-natural bit ordering. It forces the opcode byte to be
> located at byte[0] so it comes first in the instruction flow.
> 
> >  That is, if an instruction is stored at address (A), the
> > MSByte (which is probably the opcode) is stored at (A+3), and the
> > immediately following instruction starts at (A+4).
> people are/were not used to having the opcode at the last position,
> hence the bit-reversing. if we re-reverse the bits, we have to
> change the endianness too, which is not a huge problem in itself,
> after all.

IMHO, the instruction should have the opcode in bits 24...31 (with bit
31 being the most significant one).  That way, if you have to steal bits
for flags, you can take the less significant ones.  As a result, there
will be a contiguous range of 8-bit opcodes that belongs to the same
instruction (while it's not contiguous when you steal the MSBit(s)).
Additionally, with the opcode occupying the MSByte, all variants of an
instruction will be encoded as numbers from a contiguous range.

If the resulting 32-bit instruction word is stored little-endian or
big-endian doesn't really matter, except in old-style (bytewise) hexdumps.

My personal confession is that the address of a byte shall directly
indicate its significance -- most significant byte at highest address,
least significant byte at lowest address -- and that's little-endian.
It also has the nice property that `*(type*)&x == (type)x' in C, when
`x' has an arbitrary integer type and `type' is a smaller integer type.

But I'm not interested in starting a Holy War(tm) here.

-- 
 Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
 "All I wanna do is have a little fun before I die"
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/