Re: [Tack-devel] any chance of targeting 64-bit?

[Antoine L. <ant...@gm...>]

Le 16/09/2014 09:04, u-...@ae... écrivit :
> On Mon, Sep 15, 2014 at 10:39:39PM +0200, David Given wrote:
>> Okay, 64 bit. I... don't know, actually. I don't think anyone's tried
>> it. I don't think there's any reason why it wouldn't work,

I do see a reason for problems: as far as I know, there is no support
for any form of 64-bit (8-byte) arithmetic in ACK.
I believe this will be a prerequisite (which would be otherwise welcome)

> What I had in mind was x86_64.

As David explained, front-end will be (mostly?) unchanged.

Within the back-end part, one thing is the assembler: x86-64 assembler
are just improved i386 assemblers, with a new .use64 mode (in addition
to .use16 and .use32) acting on instructions like INC and DEC, a new
.rex pseudo-mnemonic similar to a16/a32 and o16/o32, and a bunch of
similar things (SSE comes to my mind...) Nothing really difficult, and
furthermore this is essentially disconnected from the rest of the stuff
and can be worked on directly on the i386 (that is, that improved
"amd64" as could be used directly in place of i386 as within the rest of
the i386-targetting compiler, and it should continue to work OK.) The
base code is in mach/i386/as/*.c (where mach0.c and mach1.c are actually
.h, and mach2.c is actually yacc .y code) to be used along with
mach/proto/as/*. A nice sub-project if you ask me.

The other part is the code generator, which again would derive from
i386/ncg/* I have no experience creating a new CGG target but I do not
believe this has to be very complex... once there is support for 8-byte
operands in the infrastructure (I know about cst8 and OP64, but I do not
believe they have been much tested in real...)


Another project, which would certainly be the way it has to be done in
the '80s but could be, or could not be, easier now, would be to develop
a "em48" target with its relevant interpreter improvements.
I do not know if this would also require the corresponding "em88"
target, particularly for the arithmetic stuff I was writing above.


> (Iow I am not motivated by the absence of other compilers for the platform,
> but rather look for diversity/alternatives).
> 
>>>> weird object file format.
>>
>> ...which reminds me: the ack.out object file format doesn't know about
>> 64-bit relocations, so you'd need to add support for that.

Mmmm, it would be a bit more that just relocations...

I see basically two ways to deal with x86-64 relocatable code:
The easy is to *ignore* relocations regarding the two operations (MOV
RXX,imm64 and MOV RAX,(ofs64)) which are dealing with full-size 64-bit
operands, and keep the whole thing using 32 bits all over the place.
The other way involve using 64-bit addresses, and this would require
improving the linker LED, a new .out format, and much more changes...

On the other hand, .out is based on using "long" all over the place, so
perhaps just recompiling the whole thing, using 64-bit long, would do
the trick (besides being incompatible with existing .out files.)


Antoine