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 -
call a procvar (includes virtual constructors and virtual class methods),
and raise its getCause() so that the original exception is propagated to
the caller
git-svn-id: branches/jvmbackend@19030 -
r18906 from byte into sizeint (copy/paste error from the similar shortstring
helper, where both source and destination are shortstrings)
git-svn-id: branches/jvmbackend@18939 -
the JVM target, and pos/insert/delete/val/str/uniquestring/setstring/
stringofchar/... are now also available for ansistrings on the JVM
target
git-svn-id: branches/jvmbackend@18906 -
val/str for enums for now) for the JVM target: insert/delete/pos/...
* use generic unicodestring helper routines where possible for the JVM
target (not that many as for shortstrings since unicodestring is
handled using java.lang.String)
+ complete widestring manager implementation for the JVM target. It uses
a class with virtual methods rather than a record with function pointers
for speed reasons though (since no existing widestring manager will be
compatible anyway, that shouldn't cause any problems)
git-svn-id: branches/jvmbackend@18882 -
jsstringh.inc -> use generic inc/sstrings.inc
* added a bunch of extra {$ifdef FPC_HAS_XXX} protections around
routines in inc/sstrings.inc and implemented those routines for
the JVM target in java/jsstrings.inc
* use the majority of the generic routine in sstrings.inc now also
for the JVM target! Only a few changes were needed:
o in a few places, calls to move() for copying shortstring->shortstring
or shortstring->chararray were replaced with calls to a new inline
helper that calls move() in the version in inc/sstrings.inc, and
JLSystem.arraycopt() in in the version in java/jsstrings.inc
o changed the currency argument to str() for the JVM target to constref
so its address can be taken (has to be typecasted to int64 without
changing the value), and similarly changed the temporary result
inside that routine to an array of 1 elements so the address can be
taken
o don't typecast the real value to a record type in str_real for the
JVM target, but work via an int64 instead to extract sign/mantissa/exp
o everything else compiled and worked as is!!
-> val, str, hexstr/octstr/binstr, delete, pos, insert, setstring and
comparetext now all work for shortstrings on the JVM target
git-svn-id: branches/jvmbackend@18836 -
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 -
signature conflicts by declaring them as "external", so that they
map to exactly that routine they would normally conflict with
git-svn-id: branches/jvmbackend@18824 -
* fixed FpcBaseProcVarType.clone: create a new method field "pointer" and
set it (using the java.lang.reflect interface). Previously, the pointer
to the method record was copied via the inherited clone, which meant
that the original and new procvar shared it
git-svn-id: branches/jvmbackend@18816 -
and add clone() method that calls inherited clone so that in case
of reflection lookup it will be found in this class rather than
getting an exception and having to search the parent class (will
be used in threadvar implementation)
git-svn-id: branches/jvmbackend@18809 -
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 -
can be added to typecast them to pchars)
* fixed array-of-char to ansistring conversion in case of zero-based
array and an embedded #0 (didn't stop at the embedded #0)
git-svn-id: branches/jvmbackend@18766 -
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 -
in the system unit for easier debugging)
* disabled a bunch more feature flags by default for the JVM target
* incorporate modified version of inc/systemh.inc (split into two parts:
jsystemh_types.inc and jsystemh.inc, because some of the types are
required for the declaration of the shortstring/ansistring/set/...
classes, which in turn are required for the routine declarations) and
inc/system.inc (as jsystem.inc)
o moved some routines around from old to new locations based on where
they appear in the common files
o added a number of defines that allow skipping more common implementations
in case a platform-specific one is already available
* all base classes (AnsistringClass etc) are now descendants of
JLObject rather than TObject, because their declaration is now parsed
before TObject is known (and there's no need for them to inherit from
TObject)
* incorporate modified version of inc/system.inc
* use the common version of generic.inc, currh.inc, gencurr.inc and
genmath.inc (with small modification to those files)
+ addition of quite a bit of system unit functionality (halt, runerror,
random, round, str() for integer types, abs, odd, endian swapping helpers,
bit scanning, trigonometric functions, ln, exp, ...)
o round()/trunc() for comp-types has been renamed trunc_comp() on the
JVM target because their JVM signature conflicts with trunc(currency)
o the unsigned versions of swapendian() and other endian helpers are not
available on the JVM target because of JVM signature conflicts
git-svn-id: branches/jvmbackend@18746 -
+ 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 -
* catch java.lang.NoSuchMethodException exceptions when resolving a procvar,
because java.lang.Class.getDeclaredMethod() only searches that particular
class itself and not its parents -> in case we get the address of a method
that's not overridden in the current class, also search the parent classes
git-svn-id: branches/jvmbackend@18730 -
methods as "virtual" anymore (since they're not virtual, and the
compiler now handles virtual class methods differently)
git-svn-id: branches/jvmbackend@18725 -
actual recordtype into FpcBaseRecordType so we can also use
the deep copy routine in the RTL
+ added abstract fpcDeepCopy() declaration to FpcBaseRecordType class
git-svn-id: branches/jvmbackend@18718 -
ShortStringClass.FpcDeepCopy (can happen when copying value
parameters like string[4] into local storage in case a string
longer than 4 characters was passed)
* create chararray of the correct maximum length when constructing
a chararray from a constant string
* don't pass invalid ranges to JLArrays.fill() when padding a
chararray after filling it using the contents of shortstring
git-svn-id: branches/jvmbackend@18701 -
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 -
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 -
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 -
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 -
(non-dynamic arrays, records, shortstrings)
- removed the ability to typecast such types directly into related class
types, you have to use the @-operator first now to get a pointer to
the type
o updated the RTL and internal compiler code to properly use this
new convention
o allowed removing several special cases from
tjvmtypeconvnode.target_specific_general_typeconv(), and that
method can probably be removed completely over time
* no longer give compile time errors for pointer-related typecasts that
will fail at run time, because the checking was too complex and could
be worked around via actual pointer typecasts anyway
* removed some unnecessary checkcast operations (for shortstring/
shortstringclass)
git-svn-id: branches/jvmbackend@18574 -
