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

[Taylor R Campbell]

   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.