Regarding possible directions for the DLX target

[nkavv at physics dot auth dot gr]

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