as well as insert_regalloc_info_all()
+ "register" allocator for the jvm target, which simply replaces every
virtual register with a temp. This is done for all register types in
one pass, so that the temps can be easily reused without worrying
about conflicts. Small optimisation: alloc/store/dealloc/load
sequences for a single reg are removed (many of these are generated
because most cg nodes return their value in a register which is then
immediately consumed by the parent)
* map addressregisters to integer registers with size R_SUBD, because
they require one stackslot (the subregister type is used by rgcpu
to determine the size of the temp it has to allocate)
git-svn-id: branches/jvmbackend@18316 -
handle vectorfpu (floatdef->MMREG) and softfloat (floatdef->INTREG)
+ thlcg.getregisterfordef(), which uses def2regtyp() to allocate a register
appropriate to hold values of that tdef type
+ generic thlcg.location_force_reg() implementation. Note that for
low-level code generator targets it may be slightly less efficient than
the implementation in hlcg2ll (from ncgutil) because it does not play
any tricks with the register or location size, or with reference offsets,
to truncate values
git-svn-id: branches/jvmbackend@18315 -
setflags is false
* don't call the *_checkoverflow() methods from ncgadd with setflags
= true in case cs_check_overflow is disabled
git-svn-id: branches/jvmbackend@18314 -
+ basic target information for jvm target (assembling/linking
helpers are still dummies for now)
+ basic jasmin assembler writer
+ cpunode and cputarg units to include the target units in the
compiler
git-svn-id: branches/jvmbackend@18309 -
+ added arrayreftype field to treference for the jvm, because
array loads have to be performed using special instructions,
so this information has to be passed on to the code generator.
This information will have to be added in t(cg)vecnode.
* moved concatenating the generated code for a procedure to the
al_procedures list to thlcg.record_generated_code_for_procdef(),
which is overridden by jvm/hlcgcpu to attach that code to the
procdef it belongs with. The reason is that a Java class file
can only contain code for one class, so we have to write out
the assembler grouped per class instead of in the order the
routines appear in the source code
* also committed forgotten changes in psub after moving the
register allocator initialisation to hlcgobj
git-svn-id: branches/jvmbackend@18308 -
on the evaluation stack, while on the callee side they are placed
in local variables 1..n
o the jvm only supports call-by-value. call-by-reference parameters
will have to be emulated at a higher level
o similarly, ret_in_param() always returns false
o all function results are returned on the evaluation stack (both
on the caller and callee side)
git-svn-id: branches/jvmbackend@18306 -
a separate method (defaultmangledname)
* for the jvm target, call jvmmangledname() instead of defaultmangledname()
from mangledname()
* make non-strict private and protected methods "public" in the Java bytecode,
because a single Java class file contains only code from one class, and such
methods can be accessed from other classes in the same unit too
* minor fixes to the jvm mangled name generation
git-svn-id: branches/jvmbackend@18303 -
longer aligns the temp offset in case it's odd (not required for
jvm)
* ignore the "def" argument in alloctemp() for the jvm since all stack
slots can be reused for anything there, and reformatted its alloctemp()
git-svn-id: branches/jvmbackend@18297 -
default integer types)
* define CPUDEFINED in pp.pas if JVM is defined
* initialise the fpu types and currency in psystem for the JVM target
* set uinttype/sinttype to 32 bit types also for all cpu32bitaddr cpus
by default (required for JVM, which has a 64 bit alu but 32 bit
"addresses" -- an address takes up 1 stack slot, a 64 bit int two;
also, array indices are limited to 32 bit)
git-svn-id: branches/jvmbackend@18296 -
64 bit registers are represented as a pair of 32 bit registers
in a register64 struct depends on whether or not the ALU can
perform 64 bit operations -- if it can, assume there are 64
bit registers)
git-svn-id: branches/jvmbackend@18295 -
(single, double, string, widestring), basic constructors,
spilling_get_operation_type() implementation
o special: O_MOV_SOURCE/O_MOV_DEST don't make sense for this target,
since it's stack based
git-svn-id: branches/jvmbackend@18294 -
o special things:
* no tasmcond (conditions are currently encoded in opcode names,
may be changed later)
* no actual registers, just a couple of fake ones to indicate
the locals stack and the operands/evaluation stack
* no registers for the return value; they're returned on the
evaluation stack; may be handled like the x87 in the future
git-svn-id: branches/jvmbackend@18291 -
whether the mangled name is for defining a symbol, or for referencing
it later (e.g. for a call or load of its address). The reason is that
on the JVM both cases are different.
+ jvmdef unit to encode types according to the JVM rules
+ tprocdef.jvmmangledname() to encode a procdef's JVM mangled name
(the common part of defining/referencing it; tprocdef.mangledname
afterwards adorns it as required)
git-svn-id: branches/jvmbackend@18288 -
+ it_interfacejava type (not explicitly selectable via -SI nor
{$interfaces xxx}, but default for jvm target)
* disable it_interfacecom/corba for jvm target
+ init_settings for jvm that select it_interfacejava as default interface
type
+ default_class_type constant (in symconst) that is odt_javaclass for the jvm
target and odt_class for other targets (used to determine the meaning of
"type x = class" declarations)
git-svn-id: branches/jvmbackend@18286 -
by the JVM register allocator to store register values in, instead of
tt_noreuse (because almost all registers have to be mapped to temps,
no reusing these temps will blow up the stack frame a lot)
* documented the meaning of the tt_* values
* temp growing direction for jvm is also positive
git-svn-id: branches/jvmbackend@18284 -
* made ttgobj.create virtual, added a "tgobjclass: class of ttgobj = ttgobj"
variable and use that one to instantiate new temp allocators
* created ttgjvm descendant that only allows allocations of 4 or 8 bytes
(rounding allocations < 4 bytes up to 4 bytes), and that divides the
offsets/sizes by 4 so we get stack slot numbers
git-svn-id: branches/jvmbackend@18282 -
interface as cgobj, except that all type parameters are defs instead
of tcgsize. Also includes some procedures from ncgutil (over time,
all of ncgutil will probably integrated here so it can be easily
overridden)
+ hlcg2ll: pass-through implementation of thlcg that forwards everything
either to cgobj or ncgutil, for use by the classic code generator
clients (all current platforms)
+ added "def" field to tcgpara to record the tdef of the parameter
(used by the high level code generator)
git-svn-id: branches/jvmbackend@18279 -
switching from a mode that has it to a mode that doesn't have it (which
meant that all modes had it, since the default FPC mode has it)
* added default inline support to mode macpas to minimize breaking existing
code due to this switch (only TP and ISO modes now don't have it by
default)
git-svn-id: trunk@18265 -
is real before transforming a multiply into an sqr operation (fixes make
cycle after r18252, don't know where or even how it caused a wrong
optimization)
git-svn-id: trunk@18257 -
