Am 23.03.2015 um 14:47 schrieb Jonas Maebe:
Steve Hildebrandt wrote on Mon, 23 Mar 2015:
As I see it there is no generall problem with my approach. While the
location(paramgr), the interface(get_para_regoff) and the stored
data(reg: Byte; off: LongInt) are worth some discussion,
I think whatever kind of manager like approach will be taken, will
turn out to be not realy different from what I already did.
procedure get_para_regoff(proccalloption: tproccalloption; paraloc:
pcgparalocation; out reg: Byte; out off: LongInt);
Currently the default implementation does nothing but zero the reg
and off.
This would be the place for a potential libffi implementation or any
"generic" solution chosen.
The encoded information cannot be specific to a particular kind of
consumer. The encoding format should be sufficiently generic to be
able to represent the data required for all platforms, and to provide
all the information required by any implementation that will use this
information to call routines. The purpose of "manager" units is plug &
play: you just add one to the uses clause of your main program, and it
works. It cannot require compiling the entire FPC source tree and all
used units with a particular command line option.
I agree that we need a better format as said above this is worth
discussing, but unless someone knows all the edge cases we are unable to
design the data format.
The only thing that comes to my mind is either have different RTTI data
per platform and generic access, or store all information that is
neccessary for all supported platforms.
Adding the manager to the main program, does only one thing it moves the
information generation from compile to run time(not so good), while you
gain no advantage?
An arm abi manager will be of little use in a win64 program, so there
are only 2 implementations of importance fallback and win64.
Also there is no aditional cmd option we realy need, since we know what
platform we target while generating the RTTI.
Or are you reffering to compilerswitches related to how much RTTI data
is generated?
While leaving the possibility of specific corrections if need be by
overriding get_para_regoff.
Maybe it is just me missing the bigger picture, so please correct me
if I am wrong.
One example: on some PowerPC64 ABIs, if the last bytes of a record do
not fill an entire (64 bit) register (e.g. because 5 bytes are left at
the end), they must be passed in most significant bits of that
register. In the compiler this is encoded as a "shift value" for that
parameter. So you need to be able to encode these shift values in the
RTTI.
In order to support this you would simply need to open up the interface
to suit your needs, e.g. add an additional parameter that defaults to
some value if it is of no use.
If another field shift is needed, we can either encode it somhow, store
it, or generate it at runtime.
Custom-encoding everything in a platform-specific way into these reg
and offset fields (which then wouldn't have any relation to actual
registers or offset values anymore in many cases) would lead to
requiring platform-specific decoders in the RTL, which I very much
would like to avoid.
I'm also not certain whether over time 255 registers will be enough if
you also consider vector registers and all kinds of sub registers that
are possible there (single precision scalar, double precision scalar,
quad precision scaler (?), 32 bit vector (?), 64 bit vector, 128 bit
vector, 256 bit vector -- all times the number of vector parameter
registers).
Jonas
if we know we may have more than 255 registers nothings stops us from
using a QWord or whatever we need.
This kind of RTTI will need to be interpreted no matter what, all we can
do is make this a simple process.
Since supporting things like TValue.invoke, will need an assembler call
frame that is written once per platform(if you are lucky you may be able
to reuse parts).
As I see it:
we have platform specific data
we need a method for writing this data into the generated RTTI
(encoded or raw)
we need a gracefull way of handling not generated data
this should happen at compile time
either :
TABIData = record
{$IF defined(i386) or defined(x64)}
reg : Byte;
off : Integer;
{$ELSE} {$IF defined(ppc64)}
reg : Byte;
shift : Byte;
{$IFEND}
{$IFEND}
....
end;
or:
TABIData = record
case platform of
i386, arm, x64: (
reg : Byte;
off : Integer;
);
ppc64: (
reg : Byte;
shift : Byte;
);
end;
mfg Steve
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
