happens automatically when required (for constructing arrays/records;
reference counted types don't need special treatment since everything
is garbage collected)
git-svn-id: branches/jvmbackend@18453 -
implemented via classes, all descending from system.FpcBaseRecordType
(records are also considered to be "related" to system.FpcBaseRecordType
on the JVM target)
* several routines are auto-generated for all record-classes: apart
from a default constructor (if there is none), also clone (which
returns a new instance containing a deep copy of the current
instance) and deepCopy (which copies all fields of one instance
into another one)
o added new field "synthetickind" to tprocdef that indicates what
kind of synthetically generated method it is (if any), and
mark such methods also as "synthetic" in the JVM assembler code
o split off the JVM-specific parser code (e.g., to add default
constructors) into pjvm.pas
git-svn-id: branches/jvmbackend@18450 -
(and override for the JVM, making the register type for records
R_ADDRESSREGISTER instead of R_INTREGISTER there)
git-svn-id: branches/jvmbackend@18448 -
svn r17068,17071,17081,17136
* changed all init_paras code in both thlcgobj and ncgutil to use
location_get_data_ref() instead of direct a_load_loc_reg()/
ref.base:=reg so it also works with the JVM target
* changed all init_paras code so it works with targets that do
not pass an implicit high parameter for open array (and a similar
fix in ncgcal)
+ added support for initializing array (both regular and open)
"out" parameters of reference counted types on the JVM target
(the arrays will be initialised with nil rather than an empty
array for implementation reasons, see comments in compproc.inc)
* factored out calling of functions in the system unit directly
from hlcgobj
git-svn-id: branches/jvmbackend@18421 -
of functions at the caller side, since these will already be allocated
at the callee side
* added comment to cpupara explaining why we never allocate the function
result on the caller side and then pass it as an invisible parameter,
but instead always let the callee allocate it
git-svn-id: branches/jvmbackend@18420 -
disabled it under all circumstances on platforms that use garbage
collection for managed types since it's not required there
git-svn-id: branches/jvmbackend@18418 -
in case -sr is used (-sr code cannot be compiled, and is only used for
debugging; with -alr, the stack slot information is printed in the
assembler file)
git-svn-id: branches/jvmbackend@18410 -
nil-pointers typecasted to a class type, strings)
o escape ", \, #10 and #13 in string constants as required by Java
git-svn-id: branches/jvmbackend@18391 -
function, so it can be easily also used for constsym without adding
JVM-specific routines to symtype or duplicating the routine without
inheritance
+ added tconstsym support to jvmdef.jvmmangledbasename()
git-svn-id: branches/jvmbackend@18390 -
o support for copying value parameters at the callee side if they were
passed by reference in hlcg
o JVM g_concatcopy() implementation for arrays
o moved code to get length of an array from njvminl to hlcgcpu so it can
be reused elsewhere as well
o export array copy helpers from system unit for use when assigning one
array to another
o some generic support for types that are normally not implicit pointers,
but which are for the JVM target (such as normal arrays)
* handle assigning nil to a dynamic array by generating a setlength(x,0)
node instead of by hardcoding a call to fpc_dynarray_clear, so
target-specific code can handle it if required
* hook up gethltemp() for JVM ttgjvm so array temps are properly
allocated
git-svn-id: branches/jvmbackend@18388 -
o always create exceptvarsym entry for on-nodes (on all targets) to remove
some special cases when an unnamed exception was caught
o the JVM tryfinally node generates the finally code twice: once for the
case where no exception occurs, and once when it does occur. The reason
is that the JVM's static bytecode verification otherwise cannot prove
that we will only reraise the caught exception when we caught one in
the first place (the old "jsr" opcode to de-duplicate finally code
is no longer used in JDK 1.6 because it suffered from the same problem,
see Sun Java bug
http://webcache.googleusercontent.com/search?q=cache:ZJFtvxuyhfMJ:bugs.sun.com/bugdatabase/view_bug.do%3Fbug_id%3D6491544 )
git-svn-id: branches/jvmbackend@18387 -
o tobjectdef.jvm_full_typename() now gets an extra parameter to determine
whether or not the package name should be prepended, so it can be easily
used to generate the name of the .j file and of the class name inside it
git-svn-id: branches/jvmbackend@18384 -
to tasnode (like for regular Object Pascal classes)
* don't collect WPO information for Java classes in tloadvmtaddrnode.pass_1()
(devirtualization can't work for Java, since classes can always be loaded
at run time, except for final/sealed classes -- but that's not yet
implemented)
+ JVM is-node support, unified JVM type checking codegen for is- and as-nodes
git-svn-id: branches/jvmbackend@18383 -
o since the JVM does not support call-by-reference, setlength() works
by taking an argument pointing to the old array and one to the new
array (the latter is always created in advance on the caller side,
even if not strictly required, because we cannot easily create it
on the callee side in an efficient way). Then we copy parts of the
old array to the new array as necessary
o to represent creating a new dynamic array, the JVM target uses
an in_new_x tinlinenode
+ tasnode support for the JVM. Special: it can also be used to convert
java.lang.Object to dynamic arrays, and dynamic arrays of java.lang.Object
to dynamic arrays with more dimensions (arrays are special JVM objects,
and such support is required for the setlength support)
+ check whether explicit type conversions are valid, and if so, add the
necessary conversion code since we cannot simply reinterpret bit patterns
in most cases in the JVM:
o in case of class and/or dynamic array types, convert to an as-node
o in case of int-to-float or float-to-int, use java.lang.Float/Double
helpers (+ added the definitions of these helpers to the system unit)
git-svn-id: branches/jvmbackend@18378 -
for regular temps. This is required for targets that need special
handling of the temps depending on the type
* converted most gettemp() calls to gethltemp() calls
git-svn-id: branches/jvmbackend@18376 -
do nothing for finalization, assign nil pointer for dynamic arrays
and refcounted strings (not required for JVM per se, but required
because programmer's may use them without initialising them first
and then they should be empty rather than invalid)
git-svn-id: branches/jvmbackend@18368 -
(pushedparasize is already expressed in number of stackslots rather
than in bytes)
o when determining the number of stack slots to pop after calling a function
and not using its function result, round up the function result size to
the nearest multiple of 4 before determining the number os tack slots (to
correctly handle byte/word-sized results)
git-svn-id: branches/jvmbackend@18362 -
o self is encoded as "this" for javac compatibility
+ ait_jvar (for the above) and ait_jcatch (similar, for future try/catch
support) classes
+ support for smallset JVM type encoding (as int)
git-svn-id: branches/jvmbackend@18354 -
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 -
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 -
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 -
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 -
+ 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 -
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 -
(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 -
* 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 -
