[M3devel] word vs. long vs. pointer in parse.c

[Jay K]

I believe where parse.c uses BITS_PER_WORD, it should use POINTER_SIZE.
 
 
The docs allude that "word" is a register.
On Alpha32, that is 64 bits.
However on Alpha32, LONG_SIZE and POINTER_SIZE are 32.
This leads to assertion failures in parse.c about the type to the set functions being t_int.
I imagine Alpha32 is a little strange, but that it exists for better source compatibility with VAX and maybe even HP-UX, and to keep data stored in memory and on disk smaller where 32bits suffices.
(IA64 has 32bit modes also, I forgot if in HP-UX or VMS or both. Not necessarily hardware modes, but code gen modes. I wasn't planning on an IA6432_HPUX, IA6432_VMS ports though, just IA64_HPUX and IA64_VMS)
 
 
The assertion failures went away when I tried LONG_SIZE.
  For purposes of AMD64_MINGW though, LONG_SIZE might be wrong and POINTER_SIZE the all around answer.
 
 
I still have to test this on other platforms.
 
 
That leaves I think just atomics failing all over for ALPHA32_VMS.
ALPHA64_VMS I can already produce all the assembly for cm3 (including atomics apparently). I haven't yet assembled/linked/run it. Doing native-hosted builds of cm3cg might not be viable.
(Since I haven't assembled/linked, and didn't look at the code, could be the atomics are function calls.)
 
 
Another strange thing I think I saw is that sizeof(long,size_t,ptrdiff_t) with cc /pointer_size=64 is 4, but with alpha64-dec-vms-gcc it is 8.
I think we might want something like:
 
 
#if __pointer_size  == 64 /* whatever cc /pointer_size=64 defines */
typedef __int64 INTEGER;
typedef unsigned __int64 WORD;
#else
typedef ptrdiff_t INTEGER;
typedef size_t WORD;
#endif
 
 
and use INTEGER and WORD whenever C code is interoperating with Modula-3.
 
 
Maybe just punt ALPHA32_VMS?
These systems don't have gobs of memory by modern standards -- the one I'm using is multi-user and has 768MB -- so the smaller data size might be worthwhile over ALPHA64_VMS. 
?
 
 
The platform seems fairly viable so far though.
 
 
 - Jay