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 -
