The subject pretty much says it all. I'd like to use one (or if possible, two) of these registers in some assmbly code and want to know if I need to preserve them or if D will just ignore them and leave them untouched between callbacks into the assembler code?

Thanks, b.
-- 

Me Here wrote:
> The subject pretty much says it all. I'd like to use one (or if possible, two)
> of these registers in some assmbly code and want to know if I need to preserve
> them or if D will just ignore them and leave them untouched between callbacks
> into the assembler code?

ES is used by certain instructions the compiler generates (movs & friends, IIRC)
Windows exception handling uses FS.
I'm not sure about GS (nor FS on Linux, but you specified Windows so you don't care).

Me Here wrote:
> The subject pretty much says it all. I'd like to use one (or if possible, two)
> of these registers in some assmbly code and want to know if I need to preserve
> them or if D will just ignore them and leave them untouched between callbacks
> into the assembler code?

I recommend save/restoring them. GS, for example, is used in Linux for thread local storage. FS is used for exception handling. ES is used for string instructions.

== Quote from Walter Bright (newshound1@digitalmars.com)'s article
> Me Here wrote:
> > The subject pretty much says it all. I'd like to use one (or if possible, two) of these registers in some assmbly code and want to know if I need to preserve them or if D will just ignore them and leave them untouched between callbacks into the assembler code?
> I recommend save/restoring them. GS, for example, is used in Linux for thread local storage. FS is used for exception handling. ES is used for string instructions.

In general, I think following the x86 C ABI is the best approach insofar as register allocation and such is concerned.  I don't have the link handy, but I believe it was published by Sun.  If I remember correctly, the only scratch registers are EAX and EDX.


Sean

Sean Kelly wrote:

> In general, I think following the x86 C ABI is the best approach insofar as register allocation and such is concerned.  I don't have the link handy, but I believe it was published by Sun.

I don't suppose I could impose on you for a few more clues as to what you are remembering?

Every search I've done looking for x86 ABI (with or without C and/or Sun) is
turning up the
AMD64 ABI...which doesn't seem to applicable to what I'm trying to do.

(It may in the future if I ever try to code for 64-bit, but what I'm working on is so machine wordsize specific that everything will have to change anyway).

Thanks for any and all latent memory pointers you can provide :)

b.
-- 

Me Here wrote:
> Thanks for any and all latent memory pointers you can provide :)

On windows and linux, you can modify EAX, ECX and EDX. The rest must be preserved.

Me Here wrote:
> Sean Kelly wrote:
> 
>> In general, I think following the x86 C ABI is the best approach insofar as
>> register allocation and such is concerned.  I don't have the link handy, but
>> I believe it was published by Sun.
> 
> I don't suppose I could impose on you for a few more clues as to what you are
> remembering?
> 
> Every search I've done looking for x86 ABI (with or without C and/or Sun) is
> turning up the
> AMD64 ABI...which doesn't seem to applicable to what I'm trying to do. 
> 
> (It may in the future if I ever try to code for 64-bit, but what I'm working on is so machine wordsize specific that everything will have to change anyway).
> 
> Thanks for any and all latent memory pointers you can provide :)

I think this is the one I was referring to:

http://www.sco.com/developers/devspecs/abi386-4.pdf


Sean

Sean Kelly wrote:

> Me Here wrote:
> > Sean Kelly wrote:
> > 
> > > In general, I think following the x86 C ABI is the best approach insofar as register allocation and such is concerned.  I don't have the link handy, but I believe it was published by Sun.

> > Thanks for any and all latent memory pointers you can provide :)
> 
> I think this is the one I was referring to:
> 
> http://www.sco.com/developers/devspecs/abi386-4.pdf
> 
> 
> Sean

Many thanks. That is very useful.
b.
--