Board index » delphi » Delphi 1: FORBIDDEN CPU registers

Delphi 1: FORBIDDEN CPU registers

Which CPU registers do I have to be careful about using with Delphi 1.

I have an method whose self parameter is strangely ok just before the stack
frame is created, but gets replaced with a weird value immediately after the
stack frame is created (when the execution point gets moved from the "begin"
line to the first line of the method).

I do some "repne scasb" type stuff to search buffers, and I wonder if
something I'm doing here has spoilt the register set for later on.

Sam

 

Re:Delphi 1: FORBIDDEN CPU registers


: "Samuel Liddicott" <s...@campbellsci.co.uk> wrote:

Quote
>Which CPU registers do I have to be careful about using with Delphi 1.

None - only the segment registers (oh, BP and SP, too, of course). But
properly used, AX, BX, CX, DX, DI, SI should all be available, IIRC.

Delphi 1 does not do any fancy register stuff. Unfortunately.

Just by chance, you are not changing the direction flag (CLD), are
you?

Quote
>I have an method whose self parameter is strangely ok just before the stack
>frame is created, but gets replaced with a weird value immediately after the
>stack frame is created (when the execution point gets moved from the "begin"
>line to the first line of the method).

I find it hard to believe that on entry into the procedure everything
is fine and that the setup of a stack frame should change that?

Please post source code (or the disassembled code of the routine in
question).

--
Stefan.Hoffmeister (at) Uni-Passau.de
http://kakadu.rz.uni-passau.de/~w4hoff01/Delphi
   DIR: Delphi FAQs, KBs, docs

Private email regarding Delphi will usually be ignored
unless it has been expressedly invited.

Re:Delphi 1: FORBIDDEN CPU registers


Quote
>: "Samuel Liddicott" <s...@campbellsci.co.uk> wrote:

>>Which CPU registers do I have to be careful about using with Delphi 1.

>None - only the segment registers (oh, BP and SP, too, of course). But
>properly used, AX, BX, CX, DX, DI, SI should all be available, IIRC.

>Delphi 1 does not do any fancy register stuff. Unfortunately.

>Just by chance, you are not changing the direction flag (CLD), are
>you?

Err... actually... yes.  I was taught that anything that depended on the
direction flag should set (or reset) it before use....

Perhaps this is the cause.... (my search routine is an expanded copy of the
Delphi StrPos, they do CDL).

Must I do an STD before my routine quits?  Perhaps in a try-finally handler?

Quote
>>I have an method whose self parameter is strangely ok just before the
stack
>>frame is created, but gets replaced with a weird value immediately after
the
>>stack frame is created (when the execution point gets moved from the
"begin"
>>line to the first line of the method).

>I find it hard to believe that on entry into the procedure everything
>is fine and that the setup of a stack frame should change that?

I agree, but my eyes begged to differ with me.

Quote
>Please post source code (or the disassembled code of the routine in
>question).

Well - doing a "pushf" at the start of my routine, and a "popf" at the end
seems to have mended things!  I'm still blowed if I can see how it had that
affect, even if it was CLD

Thanks Stefan!

Re:Delphi 1: FORBIDDEN CPU registers


Quote
Samuel Liddicott wrote:

> >: "Samuel Liddicott" <s...@campbellsci.co.uk> wrote:

> >>Which CPU registers do I have to be careful about using with Delphi 1.

> >None - only the segment registers (oh, BP and SP, too, of course). But
> >properly used, AX, BX, CX, DX, DI, SI should all be available, IIRC.

> >Delphi 1 does not do any fancy register stuff. Unfortunately.

> >Just by chance, you are not changing the direction flag (CLD), are
> >you?

> Err... actually... yes.  I was taught that anything that depended on the
> direction flag should set (or reset) it before use....

> Perhaps this is the cause.... (my search routine is an expanded copy of the
> Delphi StrPos, they do CDL).

> Must I do an STD before my routine quits?  Perhaps in a try-finally handler?

32-bit code may rely upon the D-flag being clear upon entry, and it is
required to ensure that the flag is clear upon exit.  

16-bit code does not have to leave the flag in a particular state, but
also cannot rely upon it being in any particular state.

There is something to be said for the "push the world" instructions, but
the Object Pascal Language Guide states that:

        "Procedures and functions should preserve the BP, SP, SS, and DS
         registers.  All other registers can be modified.  Exported routines
         should preserve the SI and DI registers."

It bears repeating that the POPs must be in the opposite order from the
PUSHes!

Re:Delphi 1: FORBIDDEN CPU registers


Quote
>Samuel Liddicott wrote:
>32-bit code may rely upon the D-flag being clear upon entry, and it is
>required to ensure that the flag is clear upon exit.

>16-bit code does not have to leave the flag in a particular state, but
>also cannot rely upon it being in any particular state.

Strange, how pushf-ing and popf-ing mended things for me, and yet as you say
(and as we see below) it is not required.  I hate things like this.  Have I
really mended anything?

|function StrLen(Str: PChar): Cardinal; assembler;
|asm
|        CLD
|        LES     DI,Str
|        MOV     CX,0FFFFH
|        XOR     AL,AL
|        REPNE   SCASB
|        MOV     AX,0FFFEH
|        SUB     AX,CX
|end;

Quote
>There is something to be said for the "push the world" instructions, but
>the Object Pascal Language Guide states that:

Aye!

Quote
> "Procedures and functions should preserve the BP, SP, SS, and DS
> registers.  All other registers can be modified.  Exported routines
> should preserve the SI and DI registers."

Hmmm...

Quote
>It bears repeating that the POPs must be in the opposite order from the
>PUSHes!

Heh heh!

Thanks.

Sam

Re:Delphi 1: FORBIDDEN CPU registers


On Wed, 12 Aug 1998 14:43:37 +0100, "Samuel Liddicott"

Quote
<s...@campbellsci.co.uk> wrote:
>>Samuel Liddicott wrote:
>>16-bit code does not have to leave the flag in a particular state, but
>>also cannot rely upon it being in any particular state.

There might be some bugs in the D1 RTL code. A quick search for all
uses of the REP opcode showed that GetParStr in WPAR.ASM does not set
the direction flag explicitly - this is the implementation of the
ParamStr function - are you using this?

--
Hallvard Vassbotn
Falcon R&D, Reuters Norge AS

Other Threads