result location (NR_FUNCTION_RESULT_REG is not valid on all platforms)
o this requires passing the forced function result type (if any) to this
method
o a generic, basic thlcg.a_call_name() is now available that sets the
function result location; can be called by descendants
* the availability under all circumstances of the correct function return
type enables g_call_system_proc() on the JVM platform to now determine
by itself how many stack slots are removed by the call -> do so, instead
of manually counting them (or forgetting to do so and messing up the
maximum evaluation stack height calculations)
git-svn-id: trunk@21862 -
with the enum instance corresponding to ordinal 0 in JVM constructors,
because a virtual method called by a parent constructor may already
have assigned a different value (see tests/test/jvm/tenum2.pp). This
will result in null pointer exceptions when using such fields without
first explicitly assigning a value to them though.
The old behaviour can be restored with the new -CTenumfieldinit command
line parameter
git-svn-id: trunk@21736 -
getintparaloc + adapted all call sites of getintparaloc. This
led to a number of additional, related changes:
o corrected the type information for some getintparaloc parameters
o don't allocate some intparalocs in cases they aren't used
o changed "const tvardata" parameter into "constref tvardata" for
fpc_variant_copy_overwrite to make pass-by-reference semantics
explicit
o moved a number of routines that now have to call find_system_type()
from cgobj to hlcgobj so that cgobj doesn't have to start depending
on the symtable unit
o added versions of the cpureg alloc/dealloc methods to hlcgobj that
call through to their cgobj counter parts, so we can call save/restore
the cpu registers before/after calling system helpers from hlcgobj
(not implemented in hlcgobj itself, because all basic register
allocator functionality is still part of cgobj/cgcpu)
git-svn-id: trunk@21696 -
RS_INVALID superregister (instead of sometimes RS_NO and sometimes
RS_INVALID)
* check for RS_INVALID in tcg.g_save_registers() and ignore such entries
git-svn-id: trunk@21622 -
methods that don't have to be implemented by targets using the high
level code generator, with dummy implementations that raise an internal
error (to remove warnings about instantiating classes with abstract
methods)
* let the JVM tcg descendent derive from this new thlbasecgcpu class
git-svn-id: trunk@21098 -
ansistrings are represented by nil
* fixed type conversion of constant empty ansistring/unicodestring to
pchar/pwidechar on the JVM target
git-svn-id: branches/jvmbackend@21055 -
o support for the new codepage-aware ansistrings in the jvm branch
o empty ansistrings are now always represented by a nil pointer rather than
by an empty string, because an empty string also has a code page which
can confuse code (although this will make ansistrings harder to use
in Java code)
o more string helpers code shared between the general and jvm rtl
o support for indexbyte/word in the jvm rtl (warning: first parameter
is an open array rather than an untyped parameter there, so
indexchar(pcharvar^,10,0) will be equivalent to
indexchar[pcharvar^],10,0) there, which is different from what is
intended; changing it to an untyped parameter wouldn't help though)
o default() support is not yet complete
o calling fpcres is currently broken due to limitations in
sysutils.executeprocess() regarding handling unix quoting and
the compiler using the same command lines for scripts and directly
calling external programs
o compiling the Java compiler currently requires adding ALLOW_WARNINGS=1
to the make command line
git-svn-id: branches/jvmbackend@20887 -
class before its VMT has been built, because that's the process that looks
for inherited abstract methods that are overridden -> instead use a new
synthetic method kind (tsk_callthrough_nonabstract) that will call
through to another method (in this case a constructor) if the owning
class does not contain any abstract methods, and generates an
empty routine otherwise
git-svn-id: branches/jvmbackend@20589 -
constructors (simply do nothing), because creating an abstract class
is not possible in the JVM (and while the JVM only triggers an
exception when you actually execute code that tries to create an
abstract class, the Android platform checks this using the bytecode
verifier at class verification time and therefore stumbled over the
old code)
git-svn-id: branches/jvmbackend@20547 -
on Dalvik, because those values are obtained via an "and 255" operation
which again turns them into longint values as var as the Dalvik type
system is concerned
git-svn-id: branches/jvmbackend@20527 -
to correctly handle non-pasbool types (can't just "not" their value),
and for Dalvik (a "not pasbool" became "xori 1", which turned the value
from a boolean into an integer as far as the Dalvik type checker was
concerned)
git-svn-id: branches/jvmbackend@20525 -
after an 8/16 bit operation on Dalvik (even if the value cannot have
become too big), because otherwise its type checker complains
git-svn-id: branches/jvmbackend@20520 -
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 -
