hlcgllvm in the uses clause of every unit that calls create_hlcodegen
o prevents dependency cycles that can cause llvm codegen units to init
before the cpu variants, which is bad since the llvm versions have to
override the cpu variants in their init code (+ added checks in the
init code that they are in fact initialised later)
git-svn-id: branches/debug_eh@40410 -
Add typecasts where needed to allow for successful compilation of arm-linux target
with -CriotR options when building the compiler.
git-svn-id: trunk@40314 -
so that they can still be freed after the reference has been changed
(e.g. in case of array indexing or record field accesses) (mantis #33628)
git-svn-id: trunk@38814 -
tcpuparamanager, very similar to the existing get_volatile_registers_XXX. The
new methods are called get_saved_registers_XXX, where XXX is the register
type ("int", "address", "fpu" or "mm")
git-svn-id: trunk@38794 -
* disable fix for #33439 during bootstrapping with 3.0.x, as 3.0.x cannot compile the currency division without the fix above
git-svn-id: trunk@38558 -
inline assembly, and fixed check after r35959 (mantis #32318)
o can also subscript parameters passed by value on the stack
o can also subscript local variables, the parameters passed by reference
that are subsequently copied into a local
git-svn-id: trunk@37886 -
* changed most of the variables in the assembler readers used to store constants from aint to tcgint
as aint has only the size of the accumular while some CPUs (AVR) allow larger constants in instructions
+ allow access to absolute symbols with address type in inline assembler
* allow absolute addresses in avr inline assembler
+ tests
git-svn-id: trunk@37411 -
determine whether it's in a register if it's a pure assembler routine
* you can't "index" implicit pointers either using their fields
git-svn-id: trunk@36287 -
* compinnr.inc include file converted to a unit
* inline number field size stored in ppu increased from byte to longint
* inlines in the parse tree (when written with the -vp option) now printed with
their enum name, instead of number
git-svn-id: trunk@36174 -
The linker will always change BL to BLX if necessary, but not vice versa (linker version dependent).
"BLX label" ALWAYS changes the instruction set. It changes a processor in ARM state to Thumb state,
or a processor in Thumb state to ARM state.
git-svn-id: trunk@36086 -
directly in inline assembly: that's only possible if it's a register
parameter where the address of the record was passed (rather than the
record itself), or if a parameter has been explicitly typecasted in
Intel-style assembly using ".size"
git-svn-id: trunk@35959 -
- all reg allocs and PIC labeels before the instruction;
- all reg deallocs and reg syncs after the instruction.
It fixes bug #31135.
git-svn-id: trunk@35545 -
ad hoc set constants containing varying number cdecl-like calling
conventions
o added pocall_sysv_abi_cdecl and pocall_ms_abi_cdecl to cstylearrayofconst
o also allow C-style blocks with mwpascal instead of cdecl (mwpascal = cdecl
with "const" = "constref" for record parameters)
o did not touch cases related to name mangling and import/export names,
because those are a real mess and easily break things left and right :/
git-svn-id: trunk@35479 -
directly in inline assembly: that's only possible if it's a register
parameter where the address of the record was passed (rather than the
record itself)
git-svn-id: trunk@35424 -
o separate information for reading and writing, because e.g. in a
try-block, only the writes to local variables and parameters are
volatile (they have to be committed immediately in case the next
instruction causes an exception)
o for now, only references to absolute memory addresses are marked
as volatile
o the volatily information is (should be) properly maintained throughout
all code generators for all archictures with this patch
o no optimizers or other compiler infrastructure uses the volatility
information yet
o this functionality is not (yet) exposed at the language level, it
is only for internal code generator use right now
git-svn-id: trunk@34996 -
