| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
is handled automatically nowadays
git-svn-id: https://svn.freepascal.org/svn/fpc/trunk@42998 3ad0048d-3df7-0310-abae-a5850022a9f2
|
| |
|
|
|
|
|
|
| |
hiding the method name of the wrapped routine
o also add a few more '&' prefixes to the generated wrapper code to
prevent issues when keywords are used as identifiers
git-svn-id: https://svn.freepascal.org/svn/fpc/trunk@40634 3ad0048d-3df7-0310-abae-a5850022a9f2
|
| |
|
|
| |
git-svn-id: https://svn.freepascal.org/svn/fpc/trunk@36165 3ad0048d-3df7-0310-abae-a5850022a9f2
|
| |
|
|
|
|
| |
capability to create it as unregistered if needed.
git-svn-id: http://svn.freepascal.org/svn/fpc/trunk@32373 3ad0048d-3df7-0310-abae-a5850022a9f2
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the defs and syms (recursively) referred by inline routines and by the WPO
info
o defs and syms are no longer added immediately to the module's deflist/
symlist, even if they are created as "registered". Instead,
"doregister=true" simply means "add it to the symbol table at the
top of the symtable stack"
o normally only when a sym/def is deref'ed, it gets added to the module
symlist/deflist and defid/symid gets a (unique) value
o in cases where we use(d) the defid to construct unique names within the
current module, you now have to call call the tdef.new unique_id_str()
method. If the def was not yet registered, we will reserve room for it
in the deflist (to get a unique id), but the defid gets set to a
negative value computed from its position in the deflist. Should it
have to be written to the ppu file later on, the defid will be
modified to the actual position in the deflist. For both values,
new unique_id_str() will return the same result so that references
to this def before and after actual registrations are the same (needed
for the JVM backend, but also a good principle in general)
Overall: don't directly use symid/defid anymore to get unique identifiers,
but use tdef.new unique_id_str() instead (if necessary, a similar routine
for tsym can be added)
The result is the ppu file size gets reduced significantly after its big
increase as a result of the high level typed constant builder (which creates
a lot of defs). The result is even more efficient than before, as other
unneeded defs/syms from the localsymtables don't get saved/restored anymore
either.
git-svn-id: http://svn.freepascal.org/svn/fpc/trunk@32153 3ad0048d-3df7-0310-abae-a5850022a9f2
|
| |
|
|
|
|
|
| |
* for now all typesyms are created as registered
Note: an additional parameter instead of an overload is used for ttypesym.create as otherwise both constructors would need to be overridden in potential descendant CPU-specific classes...
git-svn-id: http://svn.freepascal.org/svn/fpc/trunk@31591 3ad0048d-3df7-0310-abae-a5850022a9f2
|
| |
|
|
|
|
|
|
|
| |
procvar in the local state of the block, and then call it insde the
generated invoke routine. We can't call it directly there, because
due to visibility reasons it may not be accessible from a regular
procedure (e.g. if it is a strict private method)
git-svn-id: http://svn.freepascal.org/svn/fpc/branches/blocks@28234 3ad0048d-3df7-0310-abae-a5850022a9f2
|
| |
|
|
|
|
|
|
| |
"reference to ...; cdecl;". The "reference to ..." syntax is what Delphi
uses for anonymous function references. The "cdecl;" indicates that this
is for the C-variant of such references, which is what blocks are
git-svn-id: http://svn.freepascal.org/svn/fpc/branches/blocks@28233 3ad0048d-3df7-0310-abae-a5850022a9f2
|
|
|
o blocks are implemented as a variation of procedure variables
o declaration of a block variable: "test: procedure(c: char) is block;"
(C equivalent: (void)(^test)(char c) )
o the compiler automatically converts procedures/functions whose address
is passed to a block parameter or assigned to a block variable into
a "block". This consists of
1) generating a block descriptor (containing the size of the "block
literal" (see below) and the signature of the invocation function
encoded as an Objective-C selector)
2) generating a wrapper function around the original funcion (with C
calling convention), that has an extra first hidden parameter
(marked as vo_is_parentfp in the compiler) whose type is a pointer
to the describing "block literal"
3) generating the "block literal", which contains a pointer to an
external variable indicating whether this block captures context or
not, some flags (see compiler/blockutl.get_block_literal_flags for
info), a pointer to the wrapper function and a pointer to the
descriptor. In the future, it will also contain captured variables.
o right now, only global procedures/functions can be converted to blocks
(because they don't require state capturing). The next steps are (Object
Pascal) methods (not Objective-C methods, because Objective-C method
procvars don't exist) and finally nested functions
o on Mac OS X, the functionality will only work on Mac OS X 10.7 and later,
because we have to use the so-called "ABI.2010.3.16" to ensure that
our blocks aren't called as variadic functions by the runtime (which
came out after the Mac OS X 10.6 release)
o while the currently implemented functionality does not require any
library support at all, there's no use enabling it on other platforms
because unless it has been confirmed to work with a blocks runtime,
there's no point in using blocks (they're just somewhat bulky procvars
right now). Enabling it on other platforms (in combination with the
GNUStep Objective-C run time), should simply be a matter of adding
the right {$linklib xxx} statement to rtl/inc/blockrtl.pp file, adding
that file to Makefile.fpc for that platform and adding that platform
to the compiler/systems.systems_blocks_supported set
git-svn-id: http://svn.freepascal.org/svn/fpc/branches/blocks@28232 3ad0048d-3df7-0310-abae-a5850022a9f2
|
