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 -
