FPC_{DIV,MOD}_QWORD now check if both inputs have their upper 32bit set
to zero and in that case use 32-bit division instead, which many
plattforms can either do in hardware or have optimized assembly code
for.
git-svn-id: trunk@28279 -
pointer type TTinyHeapPointerArithmeticType, instead of using ptruint. This
will allow us to use a huge pointer in i8086 far data memory models, in order
to allow the heap to exceed 64k.
git-svn-id: trunk@28247 -
* longjmp: restored loading of function result (d0) which got removed in r28177.
* While at the point, added test for zero, because longjmp must never return zero values.
* Assembler reader: 'fp' refers to frame pointer, not the stack pointer.
git-svn-id: trunk@28183 -
* Data registers have to be saved/restored using 'move.l', because 'move' without suffix assumes 16-bit size.
* setjmp must behave as a regular function w.r.t. removing its argument from the stack.
git-svn-id: trunk@28103 -
* records are passed by value
* records with size of 1,2 or 4 are returned in registers
* parameters with size<4 are justified on the stack according to big-endian target
Now everything except floating-point parameters is compatible with C code compiled with "-malign-int -mrtd".
Compatibility with "-mno-align-int" is achievable by changing target_info.maxCrecordalign to 2, but doings so causes a lot more troubles because RTL (incorrectly) assumes that records declared with {$PACKRECORDS C} are aligned to pointer size.
+ Reuse parameter locations. Since everything is passed on stack, it reduces code size quite a bit.
- tm68kparamanager.getintparaloc removed, generic implementation has been tested and works as expected.
git-svn-id: trunk@28083 -
the compact and large model startup code, since they're not used (we rely on
the DOS loader to check for the available memory instead)
git-svn-id: trunk@28069 -
program MCB address not to be calculated correctly, when the program is a tiny
model .exe file, leading to possible memory corruption. Previously, the code
assumed that dos_psp=CS, but that's only true for tiny .com files; tiny .exe
files have a 256-byte gap between dos_psp and CS.
git-svn-id: trunk@28032 -
the value set by -Ch or the second parameter to the $M directive). This is
equivalent to the heapmin value in Turbo Pascal 7 and ensures that the program
has at least this amount of heap space available (otherwise DOS will show a
'not enough memory' error and will refuse to load the program).
git-svn-id: trunk@28002 -
as well. Even though, in these models, the stack is dynamically allocated
(because it goes on top of the heap, but the heap is variable size), there are
still benefits:
1) the program will run on a larger stack during initialization, before the
actual stack (and heap) are ready
2) in cases, when the system is extremely low on memory, DOS will reject to
load the program if there's not enough memory for the stack the program
requires. This way the startup code can be further simplified by omitting
the 'not enough memory' check in the future (when we add the minimum heap
size to the executable reserved space as well).
git-svn-id: trunk@27903 -
