(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 -
o support for ansistring constants. It's done via a detour because the
JVM only supports UTF-16 string constants (no array of byte or anything
like that): store every ansicharacter in the lower 8 bits of an
UTF-16 constant string, and at run time copy the characters to an
ansistring. The alternative is to generate code that stores every
character separately to an array.
o the base ansistring support is implemented in a class called
AnsistringClass, and an ansistring is simply an instance of this
class under the hood
o the compiler currently does generate nil pointers as empty
ansistrings unlike for unicodestrings, where we always
explicitly generate an empty string. The reason is that
unicodestrings are the same as JLString and hence common
for Java interoperation, while ansistrings are unlikely to
be used in interaction with external Java code
* fixed indentation
git-svn-id: branches/jvmbackend@18562 -
since those names are only used for debug info. Only the names of
staticvarsyms in local symtables (typed constants, variable initialisers)
have to be mangled like that since they'll become fields in the global
scope
git-svn-id: branches/jvmbackend@18536 -
are JVM annotations used by Java's generics support. They cannot be used
for FPC's generics support, but they are useful in other cases
* emit classrefdefs as java.lang.Class, with a signature annotation that
indicates which class they actually refer to
git-svn-id: branches/jvmbackend@18534 -
only JVM constructs that are already implemented, but also ones that
will be supported in the future but that aren't implemented yet (to
make it easier to already adapt code to the future changes)
git-svn-id: branches/jvmbackend@18498 -
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 -
in a single statement, to be added later)
o the unicodestrings are internally simply java.lang.String instances
o at the language level, the unicodestrings are assignment-compatible
with java.lang.String
o constant strings can be implicitly converted to java.lang.String
o since java.lang.String is immutable, in particular changing a
single character in a string is extremely inefficient. This could
be solved by letting unicodestring map to java.lang.StringBuilder,
but that would make integration with plain Java code harder
git-svn-id: branches/jvmbackend@18470 -
implemented via classes, all descending from system.FpcBaseRecordType
(records are also considered to be "related" to system.FpcBaseRecordType
on the JVM target)
* several routines are auto-generated for all record-classes: apart
from a default constructor (if there is none), also clone (which
returns a new instance containing a deep copy of the current
instance) and deepCopy (which copies all fields of one instance
into another one)
o added new field "synthetickind" to tprocdef that indicates what
kind of synthetically generated method it is (if any), and
mark such methods also as "synthetic" in the JVM assembler code
o split off the JVM-specific parser code (e.g., to add default
constructors) into pjvm.pas
git-svn-id: branches/jvmbackend@18450 -
for the current unit and all types/routines declared in it. The
unit itself becomes a member of this namespace as well, so in
case it's called unit1, it will be x.y.z.unit1, and type tclass
declared in it will be x.y.z.tclass. Only used for the JVM
target currently
git-svn-id: branches/jvmbackend@18436 -
interfaces using "var f: field; external name 'xxx';" (necessary for
solving identifier clashes in imported classes)
git-svn-id: branches/jvmbackend@18406 -
function, so it can be easily also used for constsym without adding
JVM-specific routines to symtype or duplicating the routine without
inheritance
+ added tconstsym support to jvmdef.jvmmangledbasename()
git-svn-id: branches/jvmbackend@18390 -
o support for copying value parameters at the callee side if they were
passed by reference in hlcg
o JVM g_concatcopy() implementation for arrays
o moved code to get length of an array from njvminl to hlcgcpu so it can
be reused elsewhere as well
o export array copy helpers from system unit for use when assigning one
array to another
o some generic support for types that are normally not implicit pointers,
but which are for the JVM target (such as normal arrays)
* handle assigning nil to a dynamic array by generating a setlength(x,0)
node instead of by hardcoding a call to fpc_dynarray_clear, so
target-specific code can handle it if required
* hook up gethltemp() for JVM ttgjvm so array temps are properly
allocated
git-svn-id: branches/jvmbackend@18388 -
o tobjectdef.jvm_full_typename() now gets an extra parameter to determine
whether or not the package name should be prepended, so it can be easily
used to generate the name of the .j file and of the class name inside it
git-svn-id: branches/jvmbackend@18384 -
o since the JVM does not support call-by-reference, setlength() works
by taking an argument pointing to the old array and one to the new
array (the latter is always created in advance on the caller side,
even if not strictly required, because we cannot easily create it
on the callee side in an efficient way). Then we copy parts of the
old array to the new array as necessary
o to represent creating a new dynamic array, the JVM target uses
an in_new_x tinlinenode
+ tasnode support for the JVM. Special: it can also be used to convert
java.lang.Object to dynamic arrays, and dynamic arrays of java.lang.Object
to dynamic arrays with more dimensions (arrays are special JVM objects,
and such support is required for the setlength support)
+ check whether explicit type conversions are valid, and if so, add the
necessary conversion code since we cannot simply reinterpret bit patterns
in most cases in the JVM:
o in case of class and/or dynamic array types, convert to an as-node
o in case of int-to-float or float-to-int, use java.lang.Float/Double
helpers (+ added the definitions of these helpers to the system unit)
git-svn-id: branches/jvmbackend@18378 -
o self is encoded as "this" for javac compatibility
+ ait_jvar (for the above) and ait_jcatch (similar, for future try/catch
support) classes
+ support for smallset JVM type encoding (as int)
git-svn-id: branches/jvmbackend@18354 -
o hlcgobj support in tcgsubscriptnode.pass_2 for JVM-required functionality
o slightly different handling for class fields for the JVM than for other
platforms: instead of adding a unit-level staticvarsym with a hidden name,
rename the original (unused) field and add the staticvarsym with the original
name to the object symtable. This is required because the JVM code generator
has to know the class the field belongs to, as well as its real name
o moved tprocdef.makejvmmangledcallname() functionality mostly to
jvmdef.jvmaddtypeownerprefix() because it's also required for mangling
field symbol names
* changed the interface of jvmdef from ansistring to shortstring because
all of its results are also used in shortstring contexts (and they're
unlikely to overflow the shortstring limit)
* "protected", "private" (without strict) and implementation-only symbols
now get "package" visibility instead of "public" visibility
git-svn-id: branches/jvmbackend@18349 -
name of a Java class (package/procname), extracted from jvmdef
* several fixes to jvmmangledname (po_has_importdll only applies to
unit-level procedures, replace incomplete mangling of class type names
with call to jvm_full_typename()
git-svn-id: branches/jvmbackend@18326 -
o support formal external definitions (like for objcclass)
o allow specifying an "import_dll" for external Java classes, which can
be used to specify the Java package name (like the dll for cppclass)
o take the package name into account when mangling the Java class name
o several messages that were specific to Objective-Pascal classes have
been generalised because they also apply to Java classes, same for
several compiler function names
o disabled some proccall directives for Java, but more needs to happen
(Java methods are always either instance-virtual or class-static)
git-svn-id: branches/jvmbackend@18319 -
whether the mangled name is for defining a symbol, or for referencing
it later (e.g. for a call or load of its address). The reason is that
on the JVM both cases are different.
+ jvmdef unit to encode types according to the JVM rules
+ tprocdef.jvmmangledname() to encode a procdef's JVM mangled name
(the common part of defining/referencing it; tprocdef.mangledname
afterwards adorns it as required)
git-svn-id: branches/jvmbackend@18288 -
