Expand/Shrink

pLoadMint

Syntax:
#ilASM{ 
    [32]
        mov eax,[var]
        call :%pLoadMint    -- eax:=(int32)eax, edx:=hi_dword
    [64]
        mov rax,[var]
        call :%pLoadMint    -- rax:=(int64)rax
    []
      }
Description: Finish loading a machine-sized (32/64-bit) integer. Values above #3FFFFFFF (#3FFFFFFF_FFFFFFFF on 64-bit) and below -#40000000 (-#40000000_00000000 on 64-bit) are stored in an atom; this routine checks for a float ref and extracts the full 32/64 bit integer from the stored float into the accumulator. On 32-bit (only) edx receives any hi-dword, which of course means -1 for any negative-but-still-dword values. Results when var is a fraction (such as 1.99) or beyond the range of the accumulator (such as 1e23) are undefined/unpredictable/unsupported.

Memory addresses can often be stored /4 in an integer, which may prove simpler than using an atom and this routine:

integer pMem4 = allocate(N)/4
    ...
    #ilASM{ mov eax,[pMem4]
            mov [ebx+eax*4],xxx }


Note that 64-bit values must be signed: attempts to store/retrieve values above +#7FFFFFFF_FFFFFFFF will fail. You could subtract #1_00000000_00000000 to get around that when storing: on retrieval the correct bit-pattern will be in rax and it is up to you to treat that as signed/unsigned as needed. On 32-bit, atoms are limited to 53 bits of precision, so you may have bigger problems that will go away if you store 64-bit values as pairs of dwords/atoms. All 32-bit values (on 32-bit), signed or not (ie -#40000000..+#FFFFFFFF) are handled, however of course both -1 and +#FFFFFFFF will leave the same bit-pattern in eax (in which case inspecting edx may or may not be helpful). The 32-bit code in builtins\VM\pfileioN.e assumes that (unsigned) 53 bit integers are sufficient for file offsets (being somewhere in the order of 8192TB, far bigger than any currently available hard drive).
On return: all other registers preserved (ebx/rbx is re-set to 0, r15 is set to h4).
Defined in: builtins\VM\pHeap.e