On 06.08.2012 19:56, Rainer Stratmann wrote:
Am Monday 06 August 2012 19:34:23 schrieb Sven Barth:
You know that scanning the binary code for calls is platform dependant?
Yes.
[calling opcode] [calleradress]
calling opcode can differ and the byteorder of the adress can differ.
The problem here is the following:
Let's suppose the opcode for calling a function on x86 CPUs is 0xCA11.
Now you scan through the code looking for 0xCA11 followed by 4 bit. The
problem now is that without knowing the context of a found location
0xCA11 you don't know whether it is really a call opcode or some
immediate data that was passed to some previous opcode. This is also an
obstacle experienced by VM developers for x86 instructions (or CISC
instructions in general). For RISC instruction sets this is less
complex, but the problem exists there as well.
So you'd need to write that code for every CPU you want to support. Also
this is much harder to do for CISC CPUs like x86 than for RISC CPUs
(ARM, MIPS, etc), because the former have variable length opcodes. So
you'd basically need to write a full blown dissembler...
It seems hard. By now I support only 80x86 CPU's.
Maybe it would be more interesting to know why you need this beforehand?
So you mean you can convince me to find another solution?
I need this for internationalisation.
p1( 'german snippet' );
is put in a table (caller adress and text) if calling the first time and
translated in other languages.
If I have a list of all p1's I know which language snippet was already called
and which snippet was not yet translated (called).
If there is a new snippet in the program and called at least one time it is
added to the "must be translated list".
Another method would be if it would be possible to inc a constant at compile
time!
const counter = 0;
p1( [counter++](at compiletime!) , 'german snippet');
But this is an insurmountable obstacle for the compilerprogrammers I think.
Out of curiosity: why don't you use resourcestrings?
And why do you need the count of calls (or usages)?
Regards,
Sven
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
