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:
If integer registers where meant to be used, it is:
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
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
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
> 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
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
|Free forum by Nabble||Edit this page|