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 -
