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.
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.
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
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
