bit ordering (was : Re: [f-cpu] snapshot QDCPOC+YGASM)

[Yann Guidon <whygee@f-cpu.org>]

hi !

Michael Riepe wrote:
> 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.
some did care, in the past. now, we have disassemblers and elaborated tools
so it is pointless to you and me, but others still prefer the ol'good days...
i don't know what to choose.

> 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.
right.

> > 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).
this is what i have done on my local copy.
it makes everything smoother to write, too :-)

>  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.

the continuous ranges we a little problem with the last version...
now i think it's solved.

> If the resulting 32-bit instruction word is stored little-endian or
> big-endian doesn't really matter, except in old-style (bytewise) hexdumps.
true. However, i (personally) prefer to store in big endian, just in case
someone brags again :-)

> 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.
i agree with you about these fundamental properties.
They become meaningful with SIMD data !!!

> But I'm not interested in starting a Holy War(tm) here.
yup, there are enough flame wars on usenet, go read them if you want
to have fun :-)we have enough work here to keep us busy :-P

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/