so that they can still be freed after the reference has been changed
(e.g. in case of array indexing or record field accesses) (mantis #33628)
git-svn-id: trunk@38814 -
o separate information for reading and writing, because e.g. in a
try-block, only the writes to local variables and parameters are
volatile (they have to be committed immediately in case the next
instruction causes an exception)
o for now, only references to absolute memory addresses are marked
as volatile
o the volatily information is (should be) properly maintained throughout
all code generators for all archictures with this patch
o no optimizers or other compiler infrastructure uses the volatility
information yet
o this functionality is not (yet) exposed at the language level, it
is only for internal code generator use right now
git-svn-id: trunk@34996 -
it was AT_NONE, which is invalid and should never be used
* explicitly pass the correct value for all calls to those methods elsewhere
in the compiler
git-svn-id: trunk@34250 -
generator to the typecheck pass, so that it also works for platforms
that use the parentfpstruct way to handle accesses to nested frames
in case the array has been migrated to such a parentfpstruct
o additionally, the number of comparisons for such range checks
has been reduced from 3 (for signed indices) or 2 (for unsigned
indices) to 1 in all cases
o the range checking code is disabled for the JVM target, as the
JVM automatically range checks all array accesses itself anyway
git-svn-id: trunk@34034 -
* extend tcallnode with the ability to pass a tspecializationcontext so that tcallcandidates can do a final specialization
* the final procdef is registered at the end of tcallnode.pass_typecheck
git-svn-id: trunk@31763 -
labels of LOC_JUMP in the node's location. This generates some extra jumps
for short circuit boolean and/or-expressions if optimizations are off, but
with optimisations enabled the generated code is the same (except for JVM
because the jump threading optimisation isn't enabled there yet).
git-svn-id: trunk@31431 -
* create separate nodes for Objective-C in tloadvmtaddrnode.pass_1
instead of implicitly relying on the fact that the Objective-C
ISA field is at the same offset as the VMT of Object-Pascal
classes
o translate the resulting loads of ISA field into direct pointer
accesses, so that even on non-fragile ABI platforms we don't
go via an indirection (like clang/gcc)
git-svn-id: trunk@30947 -
required for the LLVM support (LLVM parameter support is not yet
included)
* always return the function return loc from a_call*, again as required
for the LLVM support
git-svn-id: branches/hlcgllvm@26992 -
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 -
as far as Java is concerned, they're now all arrays of JLObject.
When loading a value from them, we typecast the loaded value
to the appropriate type. This allows typecasting one pointer
type to another without getting verification errors (since an
"array of JLObject" is not compatible with "array of JLString")
- no longer allow dereferencing untyped pointers on the JVM
target, since that always results in invalid bytecode
git-svn-id: branches/jvmbackend@18819 -
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 -
pointer was in a register (has to be put into memory, because otherwise
the compiler thinks that the entire type is stored in a register instead
of only its address)
git-svn-id: branches/jvmbackend@18659 -
them to shortstringclass, make sure the address operator is
"typed" so that we don't insert useless checkcast instructions
git-svn-id: branches/jvmbackend@18621 -
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 -
o support for JVM arrays in JVM addrnodes and derefnodes (so we
can take the address of var parameters to store them in the
parentfpstruct and later dereference them)
o process loadnode.left also in tjvmloadnode.pass_generate_code() when
handling var-parameters
git-svn-id: branches/jvmbackend@18593 -
o since the JVM target has no stack/framepointer that can be passed
on to nested routines, all local variables and parameters accessed
from nested routines are grouped into a local record whose address
is passed to nested routines. The same technique is also required
for LLVM in the future
git-svn-id: branches/jvmbackend@18588 -
(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 -
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 -
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 -
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 -
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 -
