and skip comments (so it works again when -ar is used, because
tlhcgjvm.inc/decstack() insert comments in that case)
git-svn-id: branches/jvmbackend@18340 -
o changed type of opsize field of tcgcasenode from tcgsize into tdef,
and fixed compilation of other code generator units after this change
git-svn-id: branches/jvmbackend@18339 -
that's how these operations also work on other architectures
* fixed tjvmaddnode.second_generic_compare() for this new order
git-svn-id: branches/jvmbackend@18338 -
operation is 32 bit, not 64 bit (both in the compiler and in the
JVM)
* request a 64 rather than a 32 bit shift operation from tjvmshlshrnode
if the result is 64 bit (rather than in case shift value is 64 bit,
since as described above that never happens)
git-svn-id: branches/jvmbackend@18337 -
in case of -ar add to the assembler output the height of the
evaluation stack every time it's increased or decreased (to
more easily track missing/wrong inc/decstack() operations)
git-svn-id: branches/jvmbackend@18335 -
u64bit division/mod, and no overflow checking for divisions
(none yet for add nodes either, but that has to be implemented
in hlcgcpu rather than in the add-nodes themselves)
git-svn-id: branches/jvmbackend@18331 -
o handle them like for regular classes (return a class instance,
although this is technically not true since they don't return
anything; will be changed in the future)
o because of the previous point, make sure that we handle the
"function result" properly and don't pop too many values from
the evaluation stack when calling one constructor from another
o added "extra_pre_call_code" method used by njvmcal to insert
the "new" opcode to create the new class instance before
calling a constructor
o when a constructor does not call any other constructor (inherited
or otherwise), automatically insert a call to the inherited
parameterless constructor as required by the jvm standard)
TODO: check that *if* an inherited or other constructor is called
from another constructor, that it does so as the first statement/
call
git-svn-id: branches/jvmbackend@18328 -
renamed refactored routine to do_release_unused_return_value()
which by default releases temps, and if something else needs to
be done override (and call inherited if temps may have to be
released)
git-svn-id: branches/jvmbackend@18327 -
name of a Java class (package/procname), extracted from jvmdef
* several fixes to jvmmangledname (po_has_importdll only applies to
unit-level procedures, replace incomplete mangling of class type names
with call to jvm_full_typename()
git-svn-id: branches/jvmbackend@18326 -
support), passed through to original ncgutils version in thlcg2ll
+ thlcgobj.location_force_mem() implementation
* order parameters for jvm similar to those for i386 without fixed_stack,
so we don't need temporary paralocations
* converted most of ncgcal to thlcg
* disabled special handling for virtual methods for jvm in ncgcal, as all
invocations are name-based there
+ njvmcal with special jvm callnode support:
o always move the function result into a memory temp
o when freeing an unused function result, use a_pop(2) and adjust
the internal evaluation stack height counter
o after the call instruction, adjust the evaluation stack height counter
by subtracting the number of the pushed parameter slots, adjusted for
the slots taken up by the function result
git-svn-id: branches/jvmbackend@18325 -
o support formal external definitions (like for objcclass)
o allow specifying an "import_dll" for external Java classes, which can
be used to specify the Java package name (like the dll for cppclass)
o take the package name into account when mangling the Java class name
o several messages that were specific to Objective-Pascal classes have
been generalised because they also apply to Java classes, same for
several compiler function names
o disabled some proccall directives for Java, but more needs to happen
(Java methods are always either instance-virtual or class-static)
git-svn-id: branches/jvmbackend@18319 -
FindFileInExeLocations()
* search for jasmin.jar using FindFileInExeLocations and properly
build the java command line, so jasmin can be called successfully
by the compiler
* properly create separate assembler files for each class, and
correctly specify the class name and superclass for each class
(units themselves are still hardcoded to descend from java.lang.Object)
git-svn-id: branches/jvmbackend@18318 -
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 -
