their upper bound is lower than 127/32767: not necessary, and in case
of booleans not even allowed for Dalvik (because the "and" operation
turns the boolean into an integer as far as Dalvik is concerned)
git-svn-id: branches/jvmbackend@19825 -
classes, interfaces, dynamic arrays, ...) as "array of JLObject",
but instead as an array of the actual pointed-to type. The reason
for the previous behaviour was mainly that the JVM threadvar
implementation internally stores all threadvars that are
such double pointer types into an "array of JLObject". Type casting
this array to e.g. an "array of array of byte" causes an exception
even if it only contains "array of byte" instances (since the outer
array type is different). This is now solved by first taking the
element of the array and then typecasting it to the destination
type (so dynarrbyte(arr[0]) instead of pdynarrbyte(arr)^[0]).
The reason for the new (more accurate) behaviour is because the
old one caused type errors in case a double pointer field was
internally created for the nestedfpstruct support (see added
test)
git-svn-id: branches/jvmbackend@19821 -
verifier when -Cpjvmdalvik is used (including debug information). Using
-Cpjvmdalvik changes the semantics at the language-level in one case:
boolean(bytevar) will no longer return a boolean that contains the same
value as bytevar did, but will map the value to 0/1 (that also means that
such expressions cannot be passed to var-parameters in case of
-Cpjvmdalvik). Code compiled with -Cpjvmdalvik will also work fine on
the regular JVM, but it may be somewhat slower (it won't necessarily
be slower on Dalvik, because the .class -> .dex transformation
applies many optimizations itself)
git-svn-id: branches/jvmbackend@19743 -
those are also supported by the Java language (intftype.class) and required
in equivalent Pascal expressions (such as JLClass(intftype))
git-svn-id: branches/jvmbackend@19742 -
implicit pointer types into the nestedfpstruct, so that the original
parameter is properly changed when updated from inside nested routines
git-svn-id: branches/jvmbackend@19645 -
+ -CTcompactintarrayinit command line option to change the code generation
for typed array of some kind of integer-type initialization so that it
takes up less space in the bytecode (because the bytecode for all
routines, including the class initialization code that contains the
typed constant init code, is limited 64kb, large array or multiple
array constants could fairly easily bump into that limit)
git-svn-id: branches/jvmbackend@19638 -
set the external name of the underlying class type to the internal name
instead of to an (invalid) empty string
git-svn-id: branches/jvmbackend@19555 -
are used to implement procvar types, and add a constructor to the procvar
types that accept an instance implementing this interface -> much easier
and more natural to use procvar types from Java code
git-svn-id: branches/jvmbackend@19216 -
var-parameters on the JVM target for changes to the value passed
as var-parameter during the function call (because they are handled
via copy-in/copy-out, this may indicate unexpected bahviour later on).
out-parameters are checked in the same way, except if the out-parameter
is a local variable because then reading it before the call may result
in a bytecode verification error (since the variable may not yet be
initialized)
git-svn-id: branches/jvmbackend@19153 -
on the JVM target, because the generated code was invalid and I can't think
of a generic way to solve it (see added comments in njvmcal.pas)
git-svn-id: branches/jvmbackend@19055 -
o don't try to create .class files for generic types
o still generate all JVM-specific wrappers for generic types even though they
won't be written out, because when specializing all the defid's have to
match exactly
o add synthetic routine implementations after generating the specializations,
so that the synthetic routines for those specializations are also generated
(we don't specialize generic versions of the synthetic generic routines
because it's not easy or even always possible to create valid generic
versions of synthetic routines)
o Note: these are Pascal-style generics, not Java-style generics. The generic
types nor their specializations are usable from Java code (specializations
may become usable in the future)
git-svn-id: branches/jvmbackend@19047 -
to and returning them from sub routines, in order to follow the JVM
specs to the letter (not checked by the JVM bytecode verifiers, but
checked by the Android DEX verifier)
* -> also zero-extend them again at the caller side after returning
from such a function
git-svn-id: branches/jvmbackend@18919 -
required based on the source/destination sizes (like in
a_load_reg_reg(), a_load_ref_reg() and a_load_ref_ref())
git-svn-id: branches/jvmbackend@18918 -
complex parameters passed to inlined routines on the JVM target, because
it is not possible to take the address of any kind of node on the JVM
target (temp-reference nodes work for any kind of LOC_(C)REFERENCE, but
are currently only implemented for the JVM platform)
git-svn-id: branches/jvmbackend@18905 -
resultdef for internally generated method calls
* force the resulttype of methods used to build non-unicode string
constants on the JVM platform to the stringconstn's resultdef
git-svn-id: branches/jvmbackend@18832 -
as far as Java is concerned, they're now all arrays of JLObject.
When loading a value from them, we typecast the loaded value
to the appropriate type. This allows typecasting one pointer
type to another without getting verification errors (since an
"array of JLObject" is not compatible with "array of JLString")
- no longer allow dereferencing untyped pointers on the JVM
target, since that always results in invalid bytecode
git-svn-id: branches/jvmbackend@18819 -
unicodestring = java.lang.String. The reason this was the default in
the past is that this was the first string type that was implemented,
and without it being the default most code involving string operations
would fail. Now the default strings types are the same as for other
targets
+ new {$modeswitch unicodestrings} directive, that when activated
*together* with {$h+},
1) changes char into an alias for widechar
2) changes string into an alias for unicodestring
3) changes the preferred string evaluation type (in case of uncertainty)
to unicodestring
{$modeswitch unicodestrings} with {$h-} does not change anything at all
regarding the string type (it still changes the char type)
+ new uuchar unit that redefines char as widechar, and which is automatically
included by the compiler if {$modeswitch unicodestrings} is enabled
git-svn-id: branches/jvmbackend@18781 -
a generalized version of the formal var/out/constref support (this
also fixes passing string[xyz] expressions to non-formal var/out/constref
parameters)
git-svn-id: branches/jvmbackend@18774 -
also handle non-formal parameters
* do not copy in the original value in handleformalcopyoutpara() if it's
an out parameter
git-svn-id: branches/jvmbackend@18772 -
variables, class/record fields and arrays with enumtype(0) on
creation, so that using them without explicitly initializing them
doesn't cause a null-pointer exception. If enumtype(0) is not a
valid enum, they are not initialized (and since they wouldn't have
a valid value on native targets either in that case, an exception
on use is acceptable)
git-svn-id: branches/jvmbackend@18755 -
* added runerror number to JVM FpcRunTimeError exceptions
* enabled calling errorproc when a run time error occurs on the
JVM target
git-svn-id: branches/jvmbackend@18749 -
+ include mathh.inc in the system unit, implement most routines based
on java.lang.Math, and use (an unmodified!) genmath for the rest
- removed now obsolete jmathh.inc (was partial copy of mathh.inc)
- removed commented out overrides for several math routines in
njvminl (doesn't make sense to handle them inline in the compiler)
git-svn-id: branches/jvmbackend@18742 -
with wrapper calls, because the parameter nodes are already bound to the
paravarsyms of the current procdef so simply replacing the procsym and
procdef is not enough
git-svn-id: branches/jvmbackend@18739 -
types involved to determine whether or not the comparison is
unsigned (they don't always match due to bugs in the compiler,
and the sign of the comparison operation is what's used in
other code generators too)
git-svn-id: branches/jvmbackend@18734 -
(make_field_static() ) and replaced semi-duplicates of that
code with calls to this routine
* made the handling of static fields for the JVM target more
similar to that on the other targets, so that class properties
now also work there (-> updated JVM-specific code in several
places to deal with this new handling)
git-svn-id: branches/jvmbackend@18723 -
create a virtual class (factory) method that calls the constructor,
and then let the existing support for virtual class methods handle
everything
git-svn-id: branches/jvmbackend@18710 -
support those natively, so they are emulated via the procvar infrastructure
(and hence not very fast). Could probably be optimized somewhat by adding
a cache (hashmap of procvars) to the class hierarchies, maybe in the
future.
git-svn-id: branches/jvmbackend@18704 -
on the caller side whether it's a normal or class method that we are
calling, add the self-class parameter inside the invoke method if
necessary (by simply counting the number of parameters and inserting
it if we're one short)
git-svn-id: branches/jvmbackend@18699 -
their initialization can cause races between the unit they are declared
in and the class constructor they are initialized in (even if both
would be moved to the unit initialization code, a class constructor
using the set constant could run before the unit initialization code has
run)
git-svn-id: branches/jvmbackend@18698 -
o every porocedural variable type is represented by a class with one
public "invoke" method whose signature matches the signature of the
procvar
o internally, dispatching happens via java.lang.reflect.Method.invoke().
WARNING: while this allows calling private/protected or other methods
that are normally not accessible from another context, a security
manger can override this. If such a security manager is installed,
most procvars will cause security exceptions
o such dispatching also requires that all arguments are wrapped, but
that's done in the compiler-generated body of the invoke method,
so that procvars can also be called conveniently from Java code
o typecasting between a procedure of object and tmethod is supported,
as well as Delphi-style replacing of only the method pointer via
@procvar1=@procvar2.
o nested procvars are not yet supported, but most of the basic
infrastructure for them is already present
* all units/programs now get an internal __FPC_JVM_Module_Class_Alias$
type when compiled for the JVM target, which is an "external" class
that maps to the unit name. This is required to look up the
JLRMethod instances for regular functions/procedures
+ new tabstractprocdef.copyas() method that allows to create a procvar
from a procdef and vice versa
git-svn-id: branches/jvmbackend@18690 -
the functions may be called from Java code or indirectly and in that case
there's no way to guarantee that they'll be zero-extended on the caller
side
git-svn-id: branches/jvmbackend@18684 -
o primitive types are first boxed
o the parameter is passed inside an array of one class instance
o changing the parameter inside the routine (by assigning a value to it
like in Delphi.NET and different from regular Pascal code) will replace
this class instance (again boxing the value if required)
o on return, the class instance is extracted, unboxed if required, and
assigned back to the original location
o formal const parameters are handled without the extra array indirection,
since they cannot be changed
TODO: while writing tjvmcallparanode.handleformalcopyoutpara() I forgot that
calling getcopy on ttemprefnodes whose ttempcreatenode hasn't been copied
yet works fine, so that code is more complex than needed. Still have to
fix.
git-svn-id: branches/jvmbackend@18675 -
copying that over the old one into calling a dedicated fpcInitializeRec()
method that initializes the required fields. The reason is that this
initialization is performed for out-parameters, and the fpcDeepCopy()
method (used to copy one instance over another) has an out-parameter
-> infinite loop
git-svn-id: branches/jvmbackend@18674 -
o sets of enums are handled as JUEnumSet instances, others as JUBitSet
derivatives (both smallsets and varsets, to make interoperability with
Java easier)
o special handling of set constants: these have to be constructed at run
time. In case of constants in the code, create an internal constsym to
represent them. These and regular constsyms are then aliased by an
another internal staticvarsym that is used to initialise them in the
unit initialisation code.
o until they are constructed at run time, set constants are encoded as
constant Java strings (with the characters containing the set bits)
o hlcgobj conversion of tcginnode.pass_generate_code() for the genjumps
part (that's the only part of the generic code that's used by the JVM
target)
o as far as explicit typecasting support is concerned, currently the
following ones are supported (both from/to setdefs): ordinal types,
enums, any other set types (whose size is the same on native targets)
o enum setdefs also emit signatures
o overloading routines for different ordinal set types, or for different
enum set types, is not supported on the JVM target
git-svn-id: branches/jvmbackend@18662 -
pointer was in a register (has to be put into memory, because otherwise
the compiler thinks that the entire type is stored in a register instead
of only its address)
git-svn-id: branches/jvmbackend@18659 -
routine is called we don't know yet whether it has to be forced or not
for the JVM target (staticvarsyms that need initialization may still be
created during pass1 of the main program/unit code)
git-svn-id: branches/jvmbackend@18646 -
* only wrap the init/finalization code after the main program has been
completely processed (pass1, codegen), because this may influence
the required wrapping in case of the JVM target
* replace periods with slashes in the package name when constructing
the classes corresponding to the units (to execute their initialization
code) -- didn't notice this was wrong previously because due to the
incomplete wrapping, they were never being initialized until now
git-svn-id: branches/jvmbackend@18645 -
(cannot reuse the memory location on the JVM)
* optimized int_to_int conversions for certain smaller->larger types
in mem locations (can reuse the memory location on the JVM, because
stack locations are always at least 4 bytes)
git-svn-id: branches/jvmbackend@18622 -
them to shortstringclass, make sure the address operator is
"typed" so that we don't insert useless checkcast instructions
git-svn-id: branches/jvmbackend@18621 -
JDK class-style enums rather than plain ordinals like in Pascal
o for Pascal code, nothing changes, except that for the JVM target
you can always typecast any enum into a class instance (to interface
with the JDK)
o to Java programs, FPC enums look exactly like Java enum types
git-svn-id: branches/jvmbackend@18620 -
so that the result type of random dynamic array expressions doesn't suddenly
get changed into open array (causes internalerror if the size is requested),
and instead simply change the conversion type to tc_equal
git-svn-id: branches/jvmbackend@18605 -
mangled name handling ansistring rather than pshortstring based (required
for JVM target; little effect on speed, some extra memory usage)
git-svn-id: branches/jvmbackend@18597 -
o support for JVM arrays in JVM addrnodes and derefnodes (so we
can take the address of var parameters to store them in the
parentfpstruct and later dereference them)
o process loadnode.left also in tjvmloadnode.pass_generate_code() when
handling var-parameters
git-svn-id: branches/jvmbackend@18593 -
o since the JVM target has no stack/framepointer that can be passed
on to nested routines, all local variables and parameters accessed
from nested routines are grouped into a local record whose address
is passed to nested routines. The same technique is also required
for LLVM in the future
git-svn-id: branches/jvmbackend@18588 -
(non-dynamic arrays, records, shortstrings)
- removed the ability to typecast such types directly into related class
types, you have to use the @-operator first now to get a pointer to
the type
o updated the RTL and internal compiler code to properly use this
new convention
o allowed removing several special cases from
tjvmtypeconvnode.target_specific_general_typeconv(), and that
method can probably be removed completely over time
* no longer give compile time errors for pointer-related typecasts that
will fail at run time, because the checking was too complex and could
be worked around via actual pointer typecasts anyway
* removed some unnecessary checkcast operations (for shortstring/
shortstringclass)
git-svn-id: branches/jvmbackend@18574 -
* move the incstack() from a load before the potential "and" to
zero-extend, so that the maximum stack height get calculated
properly
git-svn-id: branches/jvmbackend@18565 -
o support for ansistring constants. It's done via a detour because the
JVM only supports UTF-16 string constants (no array of byte or anything
like that): store every ansicharacter in the lower 8 bits of an
UTF-16 constant string, and at run time copy the characters to an
ansistring. The alternative is to generate code that stores every
character separately to an array.
o the base ansistring support is implemented in a class called
AnsistringClass, and an ansistring is simply an instance of this
class under the hood
o the compiler currently does generate nil pointers as empty
ansistrings unlike for unicodestrings, where we always
explicitly generate an empty string. The reason is that
unicodestrings are the same as JLString and hence common
for Java interoperation, while ansistrings are unlikely to
be used in interaction with external Java code
* fixed indentation
git-svn-id: branches/jvmbackend@18562 -
so it can be intercepted by the JVM backend (it has to create an actual
array)
+ JVM support for the elem_2_open_array hook
git-svn-id: branches/jvmbackend@18561 -
* don't free function result space on stack twice if the result
is not used but a the same time has already been stored in a
temporary funcretnode location
git-svn-id: branches/jvmbackend@18556 -
voidpointerdef to java_jlobject (they're generated by generic code
in nmem; avoids an ifdef for the jvm target there)
git-svn-id: branches/jvmbackend@18554 -
are JVM annotations used by Java's generics support. They cannot be used
for FPC's generics support, but they are useful in other cases
* emit classrefdefs as java.lang.Class, with a signature annotation that
indicates which class they actually refer to
git-svn-id: branches/jvmbackend@18534 -
with java_jlstring in that case, because we have to insert the type
without L prefix and ; suffix for that opcode (which is not done for
objectdefs/recorddefs)
git-svn-id: branches/jvmbackend@18530 -
typeconversion handling
+ support for class reference types in the JVM (although without class virtual
methods, they're not that useful)
git-svn-id: branches/jvmbackend@18516 -
cannot insert typecasting checks on the assignment side, only on the
values that are being assigned
o since valid_for_assignment() is called in tassignmentnode.typecheckpass()
after typecheckpassing left and right, moved the conversion of the
typecheck nodes into JVM-specific constructs from typecheckpass to
pass_1, so that they can use the information whether they are on
the assignment side or not
* forbid casting a child type to a parent type on the assignment side on
managed platforms, because that circumvents the type checking
git-svn-id: branches/jvmbackend@18515 -
o moved several routines from pmodules to ngenutil and overrode them
in njvmutil (for unit initialisation tables, resource strings, ...)
o force the evaluation stack size to at least 1 for the main program,
because the unit initialisation triggers are inserted there afterwards
and they require one stack slot
git-svn-id: branches/jvmbackend@18507 -
only JVM constructs that are already implemented, but also ones that
will be supported in the future but that aren't implemented yet (to
make it easier to already adapt code to the future changes)
git-svn-id: branches/jvmbackend@18498 -
the types as declared in the system unit, since they can also be
used with equivalent but different types (e.g., byte vs shortint)
git-svn-id: branches/jvmbackend@18487 -
assignment-nodes. For global typed constants and typed constants/
local variable initialisers in regular functions/procedurs, the
assignments are performed in the unit initialisation code. For
those in object/record definitions and their methods, it's done
in the class constructor. Since we may not yet have parsed all
method implementations when the class constructor is parsed, part
of these may be initialised in a helper routine called from the
class constructor. The ones known when the class constructor is
parsed are inited there, because the ones marked as "final" and
declared as static class fields must be initialised in the class
constructor for Java
o new set systems_typed_constants_node_init in systems unit that
indicates that a target uses node trees to initialise typed consts
instead of an initialised data section
o mark typed constants in {$j-} mode as "final" for JVM
o mangle the name of staticvarsyms inside localtables a bit to avoid
name clashes (only with procedure names for now, no parameters yet
so can still cause problems with overloaded routines)
o after a routine has been parsed, it is now processed by
cnodeutils.wrap_proc_body(), which can add extra nodes before code
generation (used for injected the typed constant node trees)
git-svn-id: branches/jvmbackend@18475 -
in a single statement, to be added later)
o the unicodestrings are internally simply java.lang.String instances
o at the language level, the unicodestrings are assignment-compatible
with java.lang.String
o constant strings can be implicitly converted to java.lang.String
o since java.lang.String is immutable, in particular changing a
single character in a string is extremely inefficient. This could
be solved by letting unicodestring map to java.lang.StringBuilder,
but that would make integration with plain Java code harder
git-svn-id: branches/jvmbackend@18470 -
o when allocating array temps for the JVM target, use the specified
"forcesize" for the first dimension, since the arraydef size may
be invalid (e.g., in case it's an array constructor)
git-svn-id: branches/jvmbackend@18468 -
asis_target_specific_typecheck, and if so get the real
definition of its pointedtype rather than of the classrefdef
itself (the latter would never be different from the original
one, since there are no formal external classrefdef definitions)
git-svn-id: branches/jvmbackend@18467 -
o initialise class vars that need initialisations (records, arrays) in
class constructors
o treat class constructors as having a "void" resultdef rather than the
class type for JVM (maybe has to be done in general?)
o make it possible to specify pno_noleadingdollar to
tprocdef.customprocname() so it can be used for class constructors
(their name is lower cased because it mustn't conflict with other
identifiers, since their name doesn't matter anyway)
o added tsk_empty synthetic procdef kind which, as the name implies,
generates an empty body (for class generated constructors)
+ auto-generate class constructors in case a class has class vars that
need initialisation
git-svn-id: branches/jvmbackend@18462 -
and initialise global variables that are wrapped (records, arrays)
in those sections
o check whether pd.localst is assigned in dbgjasm, because it's
not for the unit initialisation routine
o moved insertbssdata() from ncgutil to ngenutil and override it
njvmutil (it does nothing in the latter, since global variables
are added as fields to the class representing the unit; the
initialisation is done in gen_initialize_code() in thlcgjvm)
o added force_init() and force_final() methods to ngenutil, so
that targets can force init/final routines separate from the
regular managed types infrastructure (used by JVM for forcing
an init section in case of records/arrays)
git-svn-id: branches/jvmbackend@18460 -
fpcbaserecordtype for the JVM target (intercept in ncnv via new
target_specific_general_typeconv helper, handle in as/is code)
* not only check for related types in htypechk in case they are
objdefs, but always do so (records are related to jlobject/fpcbaserecord
on the JVM target)
git-svn-id: branches/jvmbackend@18458 -
use of the register (can happen if the register is unused afterwards;
remove the alloc/dealloc results in no temp being allocated for the
register, so that instruction becomes invalid)
git-svn-id: branches/jvmbackend@18455 -
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 -
