o these classes get an "enum" flag in the class files
o these classes get a class field (whose type is that same enum
class) per enum in the type, which also gets the "enum" flag
o those class fields are initialised in the class constructor
with the name of the enum and their order in the declaration
o if the enum has jumps in FPC (lowest value is not 0, or not
all values are contiguous), then we add an extra field
to hold the FPC ordinal value of the enum
o these classes get a class field valled $VALUES that contains
a reference to the aforementioned class fields in order of
declaration (= ordinal->instance mapping, JDK-mandated)
o apart from the JDK-mandated instance methods (values, valueOf),
also add FPCOrdinal (returns FPC ordinal value; same as order
of declaration in case of no jumps) instance method and FPCValueOf
(returns enum corresponding to FPC ordinal value) static class
method
o the mapping between FPC ordinals and enum instances in case of
jumps is stored in a hashmap whose size is the next prime number
greater or equal than the number of enum elements
o moved several extra JDK types to the system unit for the enum
support, and for future boxing and Java set support
o several new synthetic method identifiers to generate the enum class
methods/constructor/class constructor
o enums with jumps are ordered by FPC ordinal value in the JVM
$VALUES array so that the java.lang.Enum.doCompare() method
will properly compare them
git-svn-id: branches/jvmbackend@18616 -
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 -
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 -
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 -
nutils.pas into virtual class methods of a new tnodeutils class defined
in ngenutil (global factory: cnodeutils), so they can be overridden by
architecture-specific implementations (required by the JVM backend)
git-svn-id: branches/jvmbackend@18364 -
