Re: [f-cpu] snapshot QDCPOC+YGASM

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

hi,

Michael Riepe wrote:
> 
> On Thu, Aug 02, 2001 at 02:29:01AM +0200, Yann Guidon wrote:
> > hi,
> > i have attached the current version of my work.
> >
> > i have discovered troubles when i wanted to decode some
> > instructions that do not fit byte boundaries for the subfields,
> > ie : loadcons uses 4 bits that overlap the opcode.
> Huh?  That should not be a problem at all in C.

it's not a problem with C. I realized that with the current syntax,
i would have to bit-reverse every field to make then senseful.
for example, when the opcode is encoded/decoded in the least significant
byte, i found that the LSB of the opcode (see the #defines) became the MSB
of the byte. something was clearly wrong.


> > my proposition is to reverse the order of all the bits
> > in the manual. the instructions will be stored in big-endian
> > so the opcode always appears at the first position in a hexdump.
> > we had this kind of discussions 2 years ago and i think that the
> > effort is not large. in fact it probably eases the encoding and
> > the decoding.
> 
> In that point, the manual is confusing anyway.
mea culpa, and other's culpa too :-P

>  The bits are numbered
> from left to right, implying that the least significant bit/byte is on
> the left (contrary to usual western notational conventions which place
> it on the right).
there was a debate 2 years ago with Mathias Brossard and others.
we finally decided that :
  the instruction encoding is not subject to the same constraints as
  the data load/store, so we encode the instructions in the most
  convenient way.

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

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