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 -
fpc_truely_ansistr_Unique(), because the i386 target has an assembler
implementation for the latter but not for the former
git-svn-id: branches/jvmbackend@18925 -
in that case if an "override" directive is missing but we interpret
the declaration as an "override" anyway, make sure to replace the vmtpd
with the overriding definition or child classes will keep seeing
the abstract method in the base class and keep decreasing their abstract
method count below zero
* only decrease the abstract method count in case we're not processing
category methods
git-svn-id: branches/jvmbackend@18923 -
to and returning them from sub routines, in order to follow the JVM
specs to the letter (not checked by the JVM bytecode verifiers, but
checked by the Android DEX verifier)
* -> also zero-extend them again at the caller side after returning
from such a function
git-svn-id: branches/jvmbackend@18919 -
required based on the source/destination sizes (like in
a_load_reg_reg(), a_load_ref_reg() and a_load_ref_ref())
git-svn-id: branches/jvmbackend@18918 -
targets:
o initialize managed temps that are passed as var-parameters to the
dests-parameter of the concat routines, because they will be read and
stored in the var-parameter array (they are finalized and hence work
fine on native targets, but finalization is a nop on the JVM target)
o do not take the shortcut of comparing with nil when checking for an
empty ansi/unicodestring on managed VM targets
git-svn-id: branches/jvmbackend@18909 -
to generic.inc
* converted fpc_shortstr_concat(_multi) to use those routines so can also be
activated for the JVM port
git-svn-id: branches/jvmbackend@18907 -
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 -
complex parameters passed to inlined routines on the JVM target, because
it is not possible to take the address of any kind of node on the JVM
target (temp-reference nodes work for any kind of LOC_(C)REFERENCE, but
are currently only implemented for the JVM platform)
git-svn-id: branches/jvmbackend@18905 -
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 -
consistency with other helpers
+ added lowercase(unicodechar) and lowercase(unicodestring) overloads (for some
reason only upcase() existed for them)
git-svn-id: branches/jvmbackend@18881 -
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 -
their address is taken if they are normally passed by reference (since then
taking this address in the callee normally also gets the address of the
original variable rather than of a copy)
git-svn-id: branches/jvmbackend@18834 -
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 -
overloads for several routines that conflict on the JVM target because
their parameter types are encoded into the same signature simply as
external, e.g. swap, swapendian, odd, sqr, ...)
git-svn-id: branches/jvmbackend@18823 -
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 -
* 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 -
code generator translation (as done by some ABIs, such as most x86-64
platforms and darwin/i386)
-> all regressions in jvmbackend branch for darwin/i386 fixed
git-svn-id: branches/jvmbackend@18806 -
oo_has_destructor is inherited from the parent class (because it
influences whether a VMT is required for TP-style objects),
so use separate oo_has_new_destructor flag instead
git-svn-id: branches/jvmbackend@18797 -
accidentally committed a long time ago (it was done to test the
generic hlcg conversion -- which in a sense was good, because it
just uncovered the bug fixed in svn trunk r18792, i.e. a bug
not specific to the hlcg conversion)
git-svn-id: branches/jvmbackend@18795 -
