|
| 1 | +If you try to build Executor on a 64-bit machine, without telling the |
| 2 | +compiler to use 32-bit pointers, the compilation will fail due to the |
| 3 | +conversion being a work in progress. |
| 4 | + |
| 5 | +This file is a rough dump of what I've been thinking about as I've |
| 6 | +explored building Executor on a 64-bit machine. I'm about to switch |
| 7 | +to some other projects before I finish this exploration, and am |
| 8 | +writing these notes primarily for myself. There's no developer's |
| 9 | +guide to Syn68k/ROMlib/Executor, so although it's possible for someone |
| 10 | +else to finish the 64-bit mods up without me, it would take a bit of |
| 11 | +figuring out what we currently do and why, something I don't currently |
| 12 | +have the time to document. |
| 13 | + |
| 14 | +At one point we had Executor running on an Alpha using 64-bit pointers |
| 15 | +for all our native code, but 32-bit pointers for the Mac memory. We |
| 16 | +did this by altering gcc to allow us to use the ":32" bit-field |
| 17 | +notation with pointers. This worked OK and could possibly work again, |
| 18 | +but there's another way we can store 32-bits of pointer in a variable |
| 19 | +and still keep the type that the pointer points to, and that's to use |
| 20 | +a union of a 32-bit unsigned and an array of zero of the pointers we |
| 21 | +really want. |
| 22 | + |
| 23 | +For example |
| 24 | + |
| 25 | + typedef union { |
| 26 | + uint32_t p_val; |
| 27 | + SomePointerType p_type[0]; |
| 28 | + } PackedSomePointerType; |
| 29 | + |
| 30 | + PackedPointerType pp; |
| 31 | + |
| 32 | +Now pp.p_val can be the 32-bit value thats in Mac memory, with |
| 33 | +(typeof pp.p_type[0]) being the type of pointer that pp.p_val can expand to. |
| 34 | + |
| 35 | +I haven't decided exactly how to make use of this type. I've experimented with |
| 36 | +defining two macros: MAKE_HIDDEN and PACKED_MEMBER that collectively replace |
| 37 | +the two places we used to use ":32". MAKE_HIDDEN replaces the way we used to |
| 38 | +make 32-bit pointers for Handles and PACKED_MEMBER replaces the way we were |
| 39 | +putting 32-bit pointers in structs. We then need to rewrite some of the macros |
| 40 | +that we use for dereferencing our 32-bit pointers. |
| 41 | + |
| 42 | +Unfortunately, a combination of having the compiler allow us to mix |
| 43 | +and match 32-bit pointers and 64-bit pointers along with the fact that |
| 44 | +we didn't keep the Alpha port up to date means that the set of macros |
| 45 | +we're using is incomplete and some macros will need to be split into |
| 46 | +different variants for different uses. For example, HxX dereferences |
| 47 | +a handle and then picks up the field that is pointed to, but does not |
| 48 | +swap the field. We can make a HxX that does that in general, but code like |
| 49 | +this: |
| 50 | + |
| 51 | + if (t_aux_c && HxX (t_aux_c, acCTable)) |
| 52 | + |
| 53 | +will not work though, since acCTable itself is a PACKED_MEMBER and so the |
| 54 | +test for zero vs. non-zero won't work with the union. If we introduce HxZ, |
| 55 | +a new macro that can be used for testing zero vs. non-zero, we can change |
| 56 | +the code to work right: |
| 57 | + |
| 58 | + if (t_aux_c && HxZ (t_aux_c, acCTable)) |
| 59 | + |
| 60 | +But that requires that one way or the other we determine when we need |
| 61 | +to change HxX into HxZ. |
| 62 | + |
| 63 | +Some of the other changes that need to be made include: |
| 64 | + |
| 65 | + defines like # define TheGDevice (TheGDevice_H.p) |
| 66 | + need to be # define TheGDevice ((typeof (TheGDevice_H.type[0]))(TheGDevice_H.pp)) |
| 67 | + |
| 68 | + A bunch(all?) of MR that should be PPR |
| 69 | + |
| 70 | + A bunch of RM that should be RPP (and intermediate values |
| 71 | + that are actually unions) |
| 72 | + |
| 73 | + Assignments to PACKED_MEMBER fields (including things |
| 74 | + like CopyMacHandle) |
| 75 | + |
| 76 | +Since the only reason to make Executor work on 64-bit machines is for fun, I |
| 77 | +have no idea when I'll have a chance to finish these mods. If it's something |
| 78 | +that interests you, drop me a note on Github, where my account is "ctm". |
0 commit comments