Interesting. How much memory does it take? Under A-Shell/Windows 7.0.1755.0 (compiler 1042), I need MEMORY 40M, which leaves just over 3M to spare...
Phase 2 - Adjust object file and process errors
Memory usage:
Total work space - 36676478 bytes
Label symbol tree - 5385380 bytes
Variable symbol tree - 23824944 bytes
Definition symbol tree - 1790916 bytes
Declaration tree - 3688436 bytes, 158208 nodes, 14425 call refs
Structure symbol tree - 1233397 bytes
Data statement pool - 0 bytes
Variable indexing area - 1194383 bytes
Compiler work stack - 910976 bytes
Functions & Procedures - 3515 compiled, 7504 ignored
Excess available memory - 3419688 bytes
End of compilation [sbx]
.versys prccstdsp.sbx
PRCCSTDSP.SBX -- A-Shell Version & System Information:
File Version: 1.0(139)
Program format: 0xF2F6 (compil/x?/av; requires A-Shell edit 1720+)
Program Size: 2,754,223
Object Code: 1,779,480
MAP Definitions: 954,274
Memory Required: 424,440
Auxiliary Blocks:
DynFunc Index: 20,439
Embedded Resources:
ashell.def[302]
infld.sdf[103]
xtree.def[140]
xtree.sdf[139]
ashell.sdf[103]
But I get the identical results with 7.0.1754.3.
However, if I use the Linux 64 bit version 7.0.1755.0/64, I have to request 60M, as the compiler usage is much greater, even though the resulting SBX is identical...
Memory usage:
Total work space - 57400474 bytes
Label symbol tree - 6924060 bytes
Variable symbol tree - 39708240 bytes
Definition symbol tree - 3078900 bytes
Declaration tree - 6335180 bytes, 158208 nodes, 14425 call refs
Structure symbol tree - 1992601 bytes
Data statement pool - 0 bytes
Variable indexing area - 1194383 bytes
Compiler work stack - 1366464 bytes
Functions & Procedures - 3515 compiled, 7504 ignored
Excess available memory - 1821928 bytes
End of compilation [sbx]
I have to do some administrative housekeeping to restore my EL7 system where I can generate the 32 bit version of 7.0.1754.3, but I'm pretty sure it's going to match the 32 bit Windows results.
I think you can just chalk this up to the fact that 64 bit architecture ends up requiring a lot more memory for storing data containing a lot of pointers. It shouldn't make too much difference for A-Shell applications, since the RUN format is still constrained to 24 bit offsets and changing the OS architecture doesn't affect the RUN variable structures. So you don't need to otherwise increase the size of your MEMORY partitions. But the compiler is a special case, since it creates massive linked/tree structures in memory to keep track of all the variables, labels, etc. until they can be converted to numeric offsets in phase 2 of the compilation.
