Native support for 64bit builds

[digulla]

It would be nice if r3 supported 64bit platforms natively.

Currently, you have to install a 32bit compatibility layer to build and run REBOL on 64 bit platforms.

[earl]

Thanks for your report. This is also tracked by the following CureCode issue: http://issue.cc/r3/1785

[carls]

What happens when you try building with -m64? Of course, in src/core/b-init.c, disable the sizeof asserts.

[leahneukirchen]

I tried this with the first public version, and it instantly crashed, after disabling the sizeofs:

juno r3@master/make% file r3
r3: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x03f9e0707fd7d030be70ba1f83521902ae7b3f9c, stripped
juno r3@master/make% ./r3
REBOL System Error:
REBOL System Error #1001: boot failure

Program terminated abnormally.
This should never happen.
Please contact www.REBOL.com with details.

[memfrag]

I've built and run a 64-bit executable successfully, or at least apparently successfully. I had to disable a few asserts, but since I don't yet understand what the asserts are asserting, it may cause other problems. :-) Anyway, I disabled the following asserts:

In core/m-pools.c:

    // Verify that size matches pool size:
    if (pool_num < SERIES_POOL) {
        ASSERT(Mem_Pools[pool_num].wide == size, RP_FREE_NODE_SIZE);
    }

In core/b-init.c:

    ASSERT(VAL_TYPE(&val) == 123,  RP_REBVAL_ALIGNMENT);
    ASSERT(sizeof(REBVAL) == 16,   RP_REBVAL_ALIGNMENT);
    ASSERT1(sizeof(REBDAT) == 4,   RP_BAD_SIZE);
    ASSERT1(sizeof(REBGOB) == 64,  RP_BAD_SIZE);

[earl]

@memfrag Very cool, thanks for chiming in. But I'm wondering: this alone gives you something that runs?

I've got to very similar changes so far, but still get an error when trying to run the binary:

$ ./r3
REBOL System Error:
REBOL System Error #1000: boot failure

Program terminated abnormally.
This should never happen.

This seems to be in the decompression of the boot script. Will try to disable boot script compression next, when I find some time.

[memfrag]

@earl Now that you mention it, I also had to disable:

if (!CHECK_STRUCT_ALIGN) Host_Crash("Incompatible struct alignment");

I noticed that you had disabled this line as well though.

But to answer your question: Yes, this gives me something that runs.

I have made a couple of changes in the Zlib code to get the code to compile at all in Xcode on my Mac, maybe this is the difference, since "System Error #1000: boot failure" (RP_BOOT_DATA) originates from the following code section:

    text = Decompress(&spec, 0, -1, 200000, 0);
    Free_Mem(code, NAT_SPEC_SIZE+1);
    if (!text) Crash(RP_BOOT_DATA);

Like you said, decompression of the boot script must not be working for you.

I am running on Mac OS X 10.8.2 and I am compiling with Clang/LLVM.

[earl]

Could you post a diff of your zlib changes somewhere? Would be quicker to try that than disabling the boot script compression altogether. (FYI: I'm working on Linux with GCC, which did not error out on the zlib code.)

[memfrag]

Sure, I will do that tomorrow though. Have to go to bed right now. :-)

[earl]

No hurries, thanks :)

[memfrag]

The changes I did in u-zlib.c can be achieved by undefining the DEBUG macro, so now I just added -UDEBUG to the C flags for that particular file.

So, all I have done to make Rebol run in 64-bit on OS X was to remove the previously mentioned asserts and then undefining DEBUG for u-zlib.c.

[earl]

Got it working yesterday myself, thanks to your prod towards Clang. On top of the the disabled assertions, I had to do two additional things:

• Use Clang (3.1) instead of GCC (4.7)
• Disable compiler optimisations (drop the -O from the makefiles)

Those changes get me working binaries on both Linux and OSX. I didn't do anything re DEBUG. Maybe you do some kind of debug build which resulted in this being defined somehow.

This gets us:

$ file ./r3
r3: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not stripped

The resulting Linux binary actually works quite well. Two tests from the core-tests test suite crash the interpreter. With those disabled, the result matches Linux 32b builds:

29-Dec-2012/21:42:41+1:00 2.101.0.4.64 Total: 4352 Succeeded: 3957 Test-failures: 53 Crashes: 12 Dialect-failures: 0 Skipped: 330

The OSX binary, on the other hand, segfaults on the test suite (haven't yet investigated further), but at least runs the console and a few scripts I tried (such as src/tools/make-boot.r).

[carls]

Ok, good to hear about this. It is what I expected. R3 runs in 64 bits, with just a few minor sanity checks disabled. (The sanity checks are there to force consistent memory operation over a wide range of platforms.)

It would be fairly easy to add a RUN_DIRTY or NOT_SANE (INSANE) symbol that disables the various checks. There may be a better name, but I don't want to call it anything-64 because this mode is useful for more than just 64 bit operation; it essentially says "I don't care how memory is organized or how efficient the code is, just run it."

In addition, some review of various unions might be worthwhile for 64 bit.

Unfortunately... I don't have a 64bit system here to test with anymore. I took it to the garbage dump many years ago.