Re: [MIT-Scheme-devel] MIT Scheme on the AMD x86-64

[Chris Hanson]

OK, I've got it working on MacOS X with changes along the lines you
suggested.  I *think* I got the Intel syntax right for SDX, but I
won't know until I set up a 64-bit Windows machine to test it.

On Tue, Nov 3, 2009 at 3:33 PM, Taylor R Campbell <address@hidden> wrote:
>   Date: Tue, 3 Nov 2009 13:17:49 -0800
>   From: Chris Hanson <address@hidden>
>
>   I've pushed some OS X changes to git, but I still haven't got a
>   working compile.
>
>   The current problem I'm looking at is this:
>
>   ./makegen/m4.sh  cmpauxmd.m4 > cmpauxmd.s
>   as -arch x86_64  -o cmpauxmd.o cmpauxmd.s
>   cmpaux-x86-64.s:309:32-bit absolute addressing is not supported for x86-64
>   as: fatal error in /usr/bin/../libexec/gcc/darwin/x86_64/as
>
>   According to a Google search, this is a deliberate restriction imposed
>   by Apple.  I think it's easily fixed, but I'll have to spend some time
>   looking at the assembly-language reference to figure out how.
>
> I remember futzing with that when I was building it on OS X, but when
> I moved to GNU/Linux, since the only x86-64 machines I have available
> run GNU/Linux, it went away and I forgot about it.  The restriction
> makes sense -- the code won't work if utility_table lies in addresses
> outside the low 4 GB.  Here's an attempt to fix it -- a new definition
> of SDX for the full SIB format, and a replacement for the solitary
> line that formerly used SDX.  If you know how to define SDX for DASM,
> fill in the question marks.
>
> ifdef(`DASM',
>      `define(SDX,`dword ptr ?????')',
>      `define(SDX,`$1($2,$3,$4)')')
>
>        # We have lots of registers free; use r9 arbitrarily.
>        OP(mov,q)       TW(ABS(utility_table),REG(r9))
>        OP(mov,q)       TW(SDX(,r9,rcx,8),REG(rax))
>
> Later I'll rewrite all of scheme_to_interface when I simplify the
> utility calling convention and rip out all x87 code, but it's time to
> make dinner, and you can try this for now.
>
> I am also thinking of redesigning the calling convention for Scheme
> procedures in order to pair CALLs and RETs, which I hear would have a
> big impact on hardware branch target prediction.  However, making this
> work with LIAR and proper tail recursion is a little tricky (and the
> current scheme I have in mind is a little hare-brained).
>
>   BTW, I noticed that you preserved most of the random windows/os2 stuff
>   in the x86-64 files.  I'm not sure about windows, but all of the os2
>   stuff can be nuked since it doesn't run in 64-bit mode and never will.
>
> You mean ASM_ENTRY_POINT in x86-64.h?  Feel free to nuke that part,
> although I have pending changes planned for the rest of the x86-64.c,
> x86-64.h, and x86-64.m4.
>