Build 64-bit binaries and libraries of R3

[Siskin-Bot]

Submitted by: abolka

Currently, we have 32-bit binaries and libraries of R3. Please provide 64-bit binaries and libraries.

This wish deliberately does not discuss the relative pros and cons, as such a discussion would miss the point: 64-bit systems simply are a fact these days, R3 should not neglect to fully and natively support them.

As R3 was described as fully 64-bit ready several times, many reckon that basic 64-bit builds should be easily doable. Getting those builds rather sooner than later would help in ironing out any kinks that might remain.

---

^{Imported from: CureCode [ Version: alpha 110 Type: Wish Platform: All Category: Platform Reproduce: Always Fixed-in:none ]
Imported from: metaeducation#1785}

Comments:

Rebolbot commented on Dec 29, 2012:

Submitted by: abolka

Additional discussion in GitHub issue rebol/rebol#45

---

Rebolbot commented on Feb 17, 2014:

Submitted by: abolka

Related pull requests (in chronological order):

rebol/rebol#142 (Shixin's original series of adaptations)
rebol/rebol#178 (Ladislav's work on top of Shixin's)
rebol/rebol#209 (178 slightly restructured and rebase for current mainline)

With the changes in 178 / 209, 64-bit builds are stable and on a par with 32-bit builds for day-to-day use.

---

Rebolbot commented on Feb 18, 2014:

Submitted by: BrianH

We should document the changes in the memory model, sizes or ranges of values that differ, stuff like that.

---

Rebolbot added the Type.wish on Jan 12, 2016

---

Hostilefork added on Mar 25, 2018

---

Hostilefork commented on Mar 25, 2018:

These modifications allowed R3-Alpha to be built as 64-bit. However, there were some issues of alignment on some systems. The use of #pragma pack allowed these to cause bugs on systems which expected 64-bit natural alignments for some types:

https://github.com/rebol/rebol/blob/25033f897b2bd466068d7663563cd3ff64740b94/src/include/sys-value.h#L41

This pragma was eliminated in Ren-C by cutting up the value cell in 3 parts instead of just 2. There is a "header" that is sizeof(void*), an "extra" which is sizeof(void*), and the "payload" which is 2*sizeof(void*). Laying it out in this way means the payload is naturally aligned on 64-bit boundaries in 64-bit builds. Also, by breaking out the "extra" into its own field that's not part of the same union as the payload, it can be inspected and modified without concern of which union type is engaged in the payload. (Assigning to a field via one union and reading out of another is undefined behavior).

---