[f-cpu] Re: snapshot QDCPOC+YGASM

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

ooops ! i had sent it to the wrong address...

Date: Thu, 02 Aug 2001 12:24:40 +0200
From: Yann Guidon <whygee@f-cpu.org>
To: f-cpu_france@april.org
Subject: Re: [ff] Re: [f-cpu] snapshot QDCPOC+YGASM

hello,

Andreas Romeyke wrote:
> Hello,
> 
> On Thu, 2 Aug 2001, Yann Guidon wrote:
> 
> > hi,
> > i have attached the current version of my work.
> Should I include these into the CVS-Repository?
no, please. the archive contains the rationale for this choice :
it's too early, and as you have seen, many things will change
and evolve. i prefer to keep total control over it. It will then
be used to derive the VHDL code, which will be under GPL.

> > 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.
> can you explain it in a better way, what the problem is (subfield
> means)? What is "loadcons"?

i meant that the instruction encoding as stated in the manual is
not good : the bit order must be swapped. for example,
the opcode was in bits 0 to 7, now it is in bits 24 to 31.
this byte is usually written first (then come the operands),
so i also swap the byte ordering to reflect it :
now i encode in big endian instead of little endian.

This means that the encoding is more straight-forward when one
looks at the opcode map and the instruction set of the manual :
the instruction is treated as an "int", and we shift ints to the
right to get the subfields (ie : flags, operands...).
Usually, one writes numbers with the most significant digit (or bit)
in the left, and the notation in the manual is the reverse, so it
caused me some troubles.

tonight, i have checked and changed my code, another snapshot will
arrive in a few days.

> > 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.
> do you mean only the assembler, is not it?
at the binary level, not the syntactic (text) description level.

> IMHO the F-CPU is a RISC, so you don't have a need to code in assembler,
> you should use a higher language instead, is not it?
RISC does not mean that you must not have an assembler.
ALL CPU have an assembler, at least as a backend to a compiler.
on top of that, maybe you should try to write a compiler and you'll
understand why they are far from perfect :-)

> If so, there is no problem with direction/endianess, because we can use
> compiler-compiler and so on.
> (At this time I did not take a look in your archive, but I want do it
> soon)
i hope it won't spoil your summer :-)

> Bye Andreas
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

PS : http://members.aol.com/carsten899/f-cpu/
the simulator has been updated !
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/