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 -
* use this counter to mark classes containing abstract methods as
"abstract" in the bytecode per the JVM spec
* also use the counter to short-circuit printing of all abstract
methods in a class when creating a new instance (we build the list
of abstract methods every time a new instance is created, which is
a waste of time if there are none in the first place)
git-svn-id: branches/jvmbackend@18635 -
property, generate a wrapper with the same visibility as the property
that calls through to the original getter/setter (JVM target only:
ensures that the JVM verifier doesn't complain about calling methods
that are not visible to the current class when using such properties
from other units/classes)
git-svn-id: branches/jvmbackend@18632 -
(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 -
