This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Regarding possible directions for the DLX target
- From: nkavv at physics dot auth dot gr
- To: nickc at redhat dot com
- Cc: binutils at sources dot redhat dot com
- Date: Sat, 31 Dec 2005 03:34:24 +0200
- Subject: Regarding possible directions for the DLX target
Hi Nick and fellow binutils users/devs,
> > 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).
>
> Is it possible that there are binaries "out there" which use the old
> opcodes ? If so then it would be desirable that these old opcodes could
> still be disassembled.
Could be. Still, this matter should only regard the "official" DLX binutils
implementation and not other variants in "homebrewed" DLX targets, as for
university courses. Notably, I suspect that most people have been using
such versions of DLX targets (e.g. one based on binutils-2.14) that were
implementing mult,multu,div,divu, with either the exact mentioned
opcodes or with opcodes in the same range but in different order (it is a
mess). The largest amount of DLX applications is in assembly form, I have not
seen much of binaries floating around the net, however we should provide a
level of compatibility to the binutils-2.16 DLX to the old binaries.
For this reason, it should be appropriate to declare a target-specific option
let's say "-dlxv2" to enable an experimental DLX interpretation. The old
version shall be the default.
Also: regarding the implementation of multiplication and division. The exact
words used by D. Patterson as the reasoning beyond using floating-point regs
for integer mult/div (!) are the following (were true around 20 years ago):
"It is rarely practical to perform a multiplication or division in the same
amount of time that an addition or register-register move takes... The second
approach is to do integer multiplication in the floating-point unit and have
it be part of the floating-point instruction set. (This is what DLX does.)"
Nowadays, most embedded processors, including synthesizable cores have a
hardware integer array multiplier (typically: 32x32, 16x16 or 32x8) requiring
1-5 cycles depending on the implementation. Software multiplication (e.g.
bit-per-cycle shift-add) is used only in low-performance systems and its rare.
Integer multiplication in DLXv1 requires something like the following:
movi2fp f0,r1
movi2fp f1,r2
mult f0,f0,f1
movfp2i r1,f0
If integer registers where meant to be used, it is:
mult r1,r1,r2
Certainly, gas does not care on the actual implementation of DLX hardware,
its purpose is to interpret correctly a DLX asm file. However, I can see here a
huge discrepancy in the original DLX specification. In the same sense, I cannot
imagine the ARMv4 requiring an FP coprocessor just for integer multiplication.
This is another reason for an improved and closer-to-production version of DLX.
More issues can follow (e.g. specifying an ABI).
> > 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 (?)
>
> It is unusual that both the quotient and the remainder would be needed
> for any given algorithm fragment, so therefore unless it is trivial to
> do, I would suggest that the div/divu instructions just produce the
> quotient.
Totally agree. New instructions (rem, remu) for extracting the remainder (A rem
B; result has the same sign to A) should be included in v2.
The %hi, %lo references could be used as macro-replacements as in the following
pseudoinstruction.
pseudo_instr("li %reg, %imm")
{
"lhi %0, (%1>>16)"; --> "lhi %0, \%hi(%1)";
"ori %0, %0, (%1&0xFFFF)"; --> "ori %0, %0, \%lo(%1)";
}
but in v2 it will be clear that they donnot correspond to actual physical
registers.
> Well I cannot really comment on the development of the DLX specification
> itself. That is more for the DLX user community. I will say that the ideal
> of the DLX binutils port should be that it provides a free, open
> implementation of the binary utilities that will as far as possible work
> with *all* variants, and not restrict users to one particular version.
> It may well want to promote a "standard" version, but if user choses to
> use a different variant they should not be forced to abandon the GNU
> binutils.
We could call v1 as the "compatibility" version, and v2 shall provide
incremental improvements on v1 regarding these issues. The v2 should be
considered "beta" for at least a period of a year (maybe more) so that
necessary feedback can be obtained, while the most obvious beneficial ideas
will be materialized during this period.
Finally, to add a texi doc on the DLX with machine dependent features would be
nice.
Best regards
Nikolaos Kavvadias