Technicalia
|
OpenEuphoria allows say allocate(107.5) and provisions 107 or 108 bytes as it sees fit, whereas in phix the programmer is forced to explicitly
round non-integers in the required direction before invoking allocate(). Technically the first parameter is an atom, to allow values above
#3FFFFFFF (on 32-bit, though a hard limit of #5FFFFFF8 applies, whereas 63-bit integers will exceed available hardware for decades yet), but it
is explicitly checked to be an exact and non-negative integer (see builtins/pAlloc.e for details).
Certain algorithms are simplified by permitting allocate(0). However the application had better not try and use that memory, and unless the flag
for automatically doing so has been used it still has to remember to free() it. In practice, allocate(0) will yield 12 or 20 bytes of useable
memory on 32/64 bit systems respectively, not that I recommend relying on that.
A minor point is that technically allocate() on 32-bit yields an unsigned address whereas on 64-bit it is treated as signed, though that is only
likely to have any effect should there be some strange OS-level address mapping going on.
As explained in builtins\VM\pHeap.e, 32-bit phix deliberately limits allocations to 1,610,612,728 bytes (8 bytes shy of #60000000) whereas in
tests 32-bit OpenEuphoria managed 1,873,463,796 (#6FAAC9F4) bytes; it is assumed this will not be an issue for any sensibly-written application.
In any case, the ability of 32-bit phix to construct (hll) strings up to 1,610,612,711 characters compared to the 32-bit OpenEuphoria (hll)
sequence limit of 468,365,949 elements(/characters) is considered to be completely exhonorating here.
Similar limits are theoretically present in 64-bit versions but significantly in excess of any machine that could physically be constructed.
|