On 12.08.2012 15:57, Rainer Stratmann wrote:
Am Sunday 12 August 2012 15:46:00 schrieb Sven Barth:
I know there is a smiley, but: Only because Jonas sees no gain in
implementing something in the compiler that would help you in your
specific case does not mean that Jonas doesn't add anything that
Am Sunday 12 August 2012 15:46:00 schrieb Sven Barth:
> I know there is a smiley, but: Only because Jonas sees no gain in
> implementing something in the compiler that would help you in your
> specific case does not mean that Jonas doesn't add anything that causes
> not much work.
That my suggesti
On 12.08.2012 15:37, Rainer Stratmann wrote:
Am Sunday 12 August 2012 15:25:17 schrieb Mark Morgan Lloyd:
Hey, Jonas, when are you introducing the optimisation that a call at the
end of a procedure can be replaced by a jmp? :-)
Jonas only introduces something if it causes not much work :-)
I
Am Sunday 12 August 2012 15:29:44 schrieb Jonas Maebe:
> Florian already implemented that quite a while ago :) I suggest to drop the
> topic though, because Rainer does not appear to be open to taking another
> approach
It depends on the approach.
If you have a better solution would you take anoth
Am Sunday 12 August 2012 15:25:17 schrieb Mark Morgan Lloyd:
> Hey, Jonas, when are you introducing the optimisation that a call at the
> end of a procedure can be replaced by a jmp? :-)
Jonas only introduces something if it causes not much work :-)
Jmp will be opcode $E9.
http://css.csail.mit.ed
On 12 Aug 2012, at 15:25, Mark Morgan Lloyd wrote:
> Rainer Stratmann wrote:
>
>> For the above mentioned purpose it works perfect since some days.
>> I got all caller adresses and even more I got all text snippets (pchar to
>> the snippet!). If you know something about assembler language then
Rainer Stratmann wrote:
For the above mentioned purpose it works perfect since some days.
I got all caller adresses and even more I got all text snippets (pchar to the
snippet!). If you know something about assembler language then it is not a
huge effort to get this information from the compil
Am Sunday 12 August 2012 09:49:36 schrieb Jorge Aldo G. de F. Junior:
> Why do you need to "Get all caller addresses of a given function procedure"
> ?
If you read the thread you will now.
Because I need an easy handling multi language interface.
> This can be solved with static code analysis - as
Why do you need to "Get all caller addresses of a given function procedure" ?
This can be solved with static code analysis - as long as there is no
procedural variables involved - but its weird to have such a
necessity... Sounds like the project started with the wrong
assumptions...
Thats my two
Am Saturday 11 August 2012 19:18:39 schrieb Jorge Aldo G. de F. Junior:
> Sorry for posting without bringing a solution, but i am curious, why
> do you need this ?
>
> Doesnt sound like good programming practice...
See Thread:
"Get all caller adresses of a given function/procedure before executing
Am Saturday 11 August 2012 17:34:44 schrieb Marco van de Voort:
> In our previous episode, Rainer Stratmann said:
> > But not the 80x86 CPU. It is still the same opcode for a call ($E8).
>
> Maybe not the call, but changing or adding address encoding is quite
> realistic.
>
> I assume you tested yo
Sorry for posting without bringing a solution, but i am curious, why
do you need this ?
Doesnt sound like good programming practice...
2012/8/11 Marco van de Voort :
> In our previous episode, Rainer Stratmann said:
>> > > There are not many different ways for a call.
>> > >
>> > > http://css.csa
In our previous episode, Rainer Stratmann said:
> > > There are not many different ways for a call.
> > >
> > > http://css.csail.mit.edu/6.858/2011/readings/i386/CALL.htm
> >
> > Yes, so the amount of effort may increase drastically. New CPU may bring
> > new ways too.
>
> But not the 80x86 CPU. I
Am Saturday 11 August 2012 14:46:53 schrieb Martin:
> On 11/08/2012 13:32, Rainer Stratmann wrote:
> > Am Saturday 11 August 2012 14:15:11 schrieb Martin:
> >> If that changes, then your code fails.
> >
> > I can easily adopt the code then.
> > There are not many different ways for a call.
> >
> >
On 11/08/2012 13:32, Rainer Stratmann wrote:
Am Saturday 11 August 2012 14:15:11 schrieb Martin:
If that changes, then your code fails.
I can easily adopt the code then.
There are not many different ways for a call.
http://css.csail.mit.edu/6.858/2011/readings/i386/CALL.htm
Yes, so the amou
Am Saturday 11 August 2012 14:15:11 schrieb Martin:
> > I do not read all discussions.
> > Which exactly headline has it?
> > Does it affect the possibility to get the information I want?
>
> Re: [fpc-devel] Re: Class field reordering
The searched procedure/function is not a class procedure or fun
On 11/08/2012 13:00, Rainer Stratmann wrote:
Am Saturday 11 August 2012 13:52:58 schrieb Martin:
On 11/08/2012 12:48, Rainer Stratmann wrote:
Am Saturday 11 August 2012 13:40:44 schrieb Rainer Stratmann:
procedure i_realy_know_what_i_am_doing( p_opcode : pbyte ; count :
longint ; proc_adr : po
Am Saturday 11 August 2012 13:52:58 schrieb Martin:
> On 11/08/2012 12:48, Rainer Stratmann wrote:
> > Am Saturday 11 August 2012 13:40:44 schrieb Rainer Stratmann:
> >> procedure i_realy_know_what_i_am_doing( p_opcode : pbyte ; count :
> >> longint ; proc_adr : pointer );
> >
> > Better: i_really_
On 11/08/2012 12:48, Rainer Stratmann wrote:
Am Saturday 11 August 2012 13:40:44 schrieb Rainer Stratmann:
procedure i_realy_know_what_i_am_doing( p_opcode : pbyte ; count : longint
; proc_adr : pointer );
Better: i_really_know_what_i_am_doing
You have read the long discussion thread, about w
Am Saturday 11 August 2012 13:40:44 schrieb Rainer Stratmann:
> procedure i_realy_know_what_i_am_doing( p_opcode : pbyte ; count : longint
> ; proc_adr : pointer );
Better: i_really_know_what_i_am_doing
___
fpc-pascal maillist - fpc-pascal@lists.freepa
20 matches
Mail list logo
