(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 -
JDK class-style enums rather than plain ordinals like in Pascal
o for Pascal code, nothing changes, except that for the JVM target
you can always typecast any enum into a class instance (to interface
with the JDK)
o to Java programs, FPC enums look exactly like Java enum types
git-svn-id: branches/jvmbackend@18620 -
so that the result type of random dynamic array expressions doesn't suddenly
get changed into open array (causes internalerror if the size is requested),
and instead simply change the conversion type to tc_equal
git-svn-id: branches/jvmbackend@18605 -
(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 -
so it can be intercepted by the JVM backend (it has to create an actual
array)
+ JVM support for the elem_2_open_array hook
git-svn-id: branches/jvmbackend@18561 -
voidpointerdef to java_jlobject (they're generated by generic code
in nmem; avoids an ifdef for the jvm target there)
git-svn-id: branches/jvmbackend@18554 -
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 -
with java_jlstring in that case, because we have to insert the type
without L prefix and ; suffix for that opcode (which is not done for
objectdefs/recorddefs)
git-svn-id: branches/jvmbackend@18530 -
typeconversion handling
+ support for class reference types in the JVM (although without class virtual
methods, they're not that useful)
git-svn-id: branches/jvmbackend@18516 -
cannot insert typecasting checks on the assignment side, only on the
values that are being assigned
o since valid_for_assignment() is called in tassignmentnode.typecheckpass()
after typecheckpassing left and right, moved the conversion of the
typecheck nodes into JVM-specific constructs from typecheckpass to
pass_1, so that they can use the information whether they are on
the assignment side or not
* forbid casting a child type to a parent type on the assignment side on
managed platforms, because that circumvents the type checking
git-svn-id: branches/jvmbackend@18515 -
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 -
the types as declared in the system unit, since they can also be
used with equivalent but different types (e.g., byte vs shortint)
git-svn-id: branches/jvmbackend@18487 -
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 -
asis_target_specific_typecheck, and if so get the real
definition of its pointedtype rather than of the classrefdef
itself (the latter would never be different from the original
one, since there are no formal external classrefdef definitions)
git-svn-id: branches/jvmbackend@18467 -
fpcbaserecordtype for the JVM target (intercept in ncnv via new
target_specific_general_typeconv helper, handle in as/is code)
* not only check for related types in htypechk in case they are
objdefs, but always do so (records are related to jlobject/fpcbaserecord
on the JVM target)
git-svn-id: branches/jvmbackend@18458 -
to tasnode (like for regular Object Pascal classes)
* don't collect WPO information for Java classes in tloadvmtaddrnode.pass_1()
(devirtualization can't work for Java, since classes can always be loaded
at run time, except for final/sealed classes -- but that's not yet
implemented)
+ JVM is-node support, unified JVM type checking codegen for is- and as-nodes
git-svn-id: branches/jvmbackend@18383 -
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 -
