Fwd: Re: Any volunteers for keeping the DLX target + maintainers patch

[nkavv at physics dot auth dot gr]

----- Forwarded message from nkavv@physics.auth.gr -----
    Date: Sat, 24 Dec 2005 02:50:39 +0200
    From: nkavv@physics.auth.gr
Reply-To: nkavv@physics.auth.gr
 Subject: Re: Any volunteers for keeping the DLX target
      To: Nick Clifton <nickc@redhat.com>


Hi Nick and all

I'm glad to help in maintaining a small bit of binutils, namely the DLX port.

AFAIK there has not been any real DLX implementation out there (with the
exception of an asynchronous prototype, the ASPIDA DLX core ?? Maybe work in
German or USA univs. circa mid-90's resulted in other DLX protos, too). My
intention is to keep the opcode map that Kuang Hwa Lin (KHL from now on) used
back in May 2002, to the extent this is possible.

Here is a first list of TODOs. Please note that since I won't be going to my
univ. office much (until early Jan.) from where binutils-cvs downloads take
very short time, I'll work on binutils-2.16 that I already have at home. I
believe that the DLX port is in the same state as in the cvs version (correct
me if i'm wrong).


========================================================================
==                           DLX port TODOs                           ==

1. I'll have a look on the set of "non-typical" DLX instructions of the port.
These are:
  "bswap"  (BSWAPF) --> A byte swap instruction
  "lut"    (LUTF)   --> No explanation whatsoever
  "ldstbu" (LSBUOP) --> Atomic load-store byte unsigned
  "ldsthu" (LSHUOP) --> Atomic load-store halfword unsigned
  "ldstw"  (LSWOP)  --> Atomic load-store word

My intention is to keep these instructions, EXCEPT lut.


2. The following "standard" DLX instructions where not implemented by KHL. Also,
the ones with an asterisk have non-unique secondary opcode mappings:
  "mult"  (MULTF)
  "multu" (MULTUF) *
  "div"   (DIVF)   *
  "divu"  (DIVUF)

For all 4 instructions I have decided on the new (secondary) opcodes
(0x18-0x1B). Also, without the HI/LO registers, only the quotient is kept for
div, divu. The remainder could be extracted by corresponding, rem, remu
instructions. Or maybe in two separate registers (?)


3. Again, regarding the multiplication/division instructions, I cannot see the
reason for still implementing these instructions with floating-point registers!
Single-cycle multipliers are available in synthesizable cores, nowadays. The
former is the approach in the Patterson book and in dlxgcc-2.7.2.3 I have been
using the last couple of days. The ARMv4 approach is to neglect the higher
32-bits of the multiplication result (unless you are executing a
multiply-long). Maybe a good choice is to provide multl, multlu primitives, for
which results are written in two consecutive registers (integer registers).
Overall, having
a floating-point register file for that is an overkill. Users should be able
to work with a pure integer DLX ISA subset (and probably with SoftFloat
emulation in gcc).


4. I have not read the Sailer book (BTW the two popular guides on DLX are the
Sailer and Patterson books). However, comparing the multiplication instructions
of DLX and most MIPS-I R2000/3000 adaptations, I come to the conclusion that
there are no HI/LO registers on DLX. Most people writing DLX models (e.g. in
Verilog, VHDL, SystemC) use them as helpers for loading 32-bit constants via
appropriate pseudo-instructions. Actually, 32-bit constants can be loaded
without HI/LO registers (with lhi,ori). Probably only the following "li"
formats should be acceptable in the future:

  li   %dest, #hi-16bit-constant, #lo-16bit-constant
  li   %dest, #32bit-constant


5. The major drawback of the DLX ISA over MIPS- is the lack of provision for
optional coprocessor mappings. There are a few ways to confront this, as:

  Move opcode(J)=0x02, opcode(JAL)=0x03 to e.g. 0x06,0x07, respectively.
  (PREFERRED)
  Move opcode(BEQZ),   opcode(BNEZ)     to      0x16,0x17.

Then the 0x01-0x04 primary opcodes would be used for 4 optional coprocessors.
Since the DLX opcode map is much more sparse than MIPS', such modifications
would be necessary for this purpose. Or should we use the currently unused
primary opcodes?


6. Add an ASCII opcode map in an appropriate file of the DLX port:
$BINUTILS\include\opcode\dlx.h. Correct some comments in:
$BINUTILS\opcodes\dlx-dis.c.


7. I'm also building an ArchC (http://www.archc.org) instruction-accurate
simulator for DLX that will include these modifications.

========================================================================

I would like to read your responses on these thoughts. Certainly, most
developers would not be interested in the DLX port (only a single reference in
the binutils Changelog over the years) but it is of high educational value. The
DLX port has its purpose: to "standardize" a neat ISA and test some ideas that
are realistic in both hardware and software (compiler) support.


Best regards
-kavi

Nikolaos Kavvadias <nkavv@physics.auth.gr>
Ph.D. Student
Dept. of Physics
Aristotle Univ. of Thessaloniki
Thessaloniki, Greece

PS: I will be using two different PCs. Due to the xxtremely high rates for ADSL
in Greece, I can't afford downloading CVS tarballs from home. Should I upload
another SSH key for the univ. PC?


----- End forwarded message -----

Attachment: binutils-2.16-maint-dlx.patch
Description: Binary data