future use by high level code generator targets
o this in turn required that all a_load*_loc* methods are called via
hlcg rather than via cg, since a location can be a subsetref/reg and
and those are no longer handled in tcg
o that then required moving several force_location_* routines into
thlcg because they use a_load_loc*, but did not take tdef size
parameters (which are required by the thlcg a_load_loc* routines)
o the only practical consequence is that from now on, you have to
use hlcg.location_force_mem/reg() (fpureg not yet) and
hlcg.gen_load_loc_cgpara() instead of the removed versions from ncgutil,
and hlcg.a_load*loc*() instead of cg.a_load*loc* if a subsetref/reg
might be involved
git-svn-id: trunk@21287 -
that deal with paths/filenames with TPathStr (= ansistring) to prevent
cutting off long paths (no change in speed when compiling the compiler,
1% extra memory usage)
git-svn-id: trunk@21120 -
o support for the new codepage-aware ansistrings in the jvm branch
o empty ansistrings are now always represented by a nil pointer rather than
by an empty string, because an empty string also has a code page which
can confuse code (although this will make ansistrings harder to use
in Java code)
o more string helpers code shared between the general and jvm rtl
o support for indexbyte/word in the jvm rtl (warning: first parameter
is an open array rather than an untyped parameter there, so
indexchar(pcharvar^,10,0) will be equivalent to
indexchar[pcharvar^],10,0) there, which is different from what is
intended; changing it to an untyped parameter wouldn't help though)
o default() support is not yet complete
o calling fpcres is currently broken due to limitations in
sysutils.executeprocess() regarding handling unix quoting and
the compiler using the same command lines for scripts and directly
calling external programs
o compiling the Java compiler currently requires adding ALLOW_WARNINGS=1
to the make command line
git-svn-id: branches/jvmbackend@20887 -
pass on whether the symbol refers to code or data (important for
AIX weak symbols; note that AIX does not support undefined weak
external symbols, and FPC does not yet support weakly defining
non-external symbols, so this functionality isn't really used yet)
git-svn-id: trunk@20802 -
of the AVR-specific ifdef'ed variant
o since the only special character we use in mangled names on all platforms
is $, added a new field to tasminfo called "dollarsign" that holds the
character $'s should be replaced with (if it doesn't have to be replaced,
leave it at $)
git-svn-id: trunk@20801 -
* Don't generate rex.w for "CALL|JMP|LCALL|LJMP regmem", they are 64-bit by default.
* LCALL,LJMP flagged as calljump instructions.
* LCALL,LJMP encode only far jumps and don't accept register operands.
* GAS writer: fixed writing rip-relative operands of calljump instructions.
+ test.
git-svn-id: trunk@19413 -
* eliminate warnings in compiler (i386 & i368->x86_64) and minor refactorings
- comment out unused vars and types
- comment out unneeded comparisons (Longword <=> 0)
- suppress some "comparison always true|false" warnings
- tweak visiblity sections
git-svn-id: trunk@19385 -
* Insert seh_endprologue directive after the last prologue instruction, not before it
* Omit seh_stackalloc for zero bytes
* (For now) ignore SEH directives in NASM and MASM writers, instead of failing with internal error.
git-svn-id: trunk@19246 -
* For now placed actual processing of unwind info under {$ifdef TEST_WIN64_UNWIND}, because in the current state it doesn't add much value.
git-svn-id: trunk@19200 -
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 -
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 -
since the definition-specific adorning of JVM mangled names is Jasmin-
specific, and such code has no place in symdef
* moved code to adorn JVM mangled names for Jasmin definitions to agjasmin
git-svn-id: branches/jvmbackend@18346 -
o changed type of opsize field of tcgcasenode from tcgsize into tdef,
and fixed compilation of other code generator units after this change
git-svn-id: branches/jvmbackend@18339 -
renamed refactored routine to do_release_unused_return_value()
which by default releases temps, and if something else needs to
be done override (and call inherited if temps may have to be
released)
git-svn-id: branches/jvmbackend@18327 -
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 -
- memory usage of a compiler compilation increases by approx. 2 per cent due to this
- actually docs say avx has operations with 5 parameter, however I were not able to find
an instruction having 5 operands
git-svn-id: trunk@18202 -
