Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Any Protected Registers with -3s ?

8 views
Skip to first unread message

Paul K. McKneely

unread,
Dec 21, 2011, 10:43:40 AM12/21/11
to
I am writing a compiler (in a parallel programming language) that will
generate assembler source that will assemble with wasm and will link to Open
Watcom C programs. I am using the -3s switch to generate 386-style stack
based calling. Does anyone know whether any of the registers must be
protected during a call? I would like to use register-based calling for
run-time routines that are called by the compiled code for efficiency and it
would be nice if all of the registers were available without having to save
and restore them.

Thanks


Paul K. McKneely

unread,
Dec 21, 2011, 12:09:49 PM12/21/11
to
I found a wikipedia article:

http://en.wikipedia.org/wiki/X86_calling_conventions

This basically says that EAX,ECX,EDX are not protected
so I can use these to pass arguments to my run time
routines. I will have to protect EBX, EBP, ESI, and EDI
internal to the routines if I use them. However, since ESI
is used to return a pointer, it seems that this could not be
protected.


Uwe Schmelich

unread,
Dec 21, 2011, 12:52:41 PM12/21/11
to
Paul K. McKneely wrote:

> I found a wikipedia article:
>
> http://en.wikipedia.org/wiki/X86_calling_conventions
>

Not sure why you are using a wikipedia article instead of the OW
documentation available. If you havn't done so please take a look into
the "Open Watcom 1.9 C/C++ User's Guide Help" around/below the
chapter "32-bit Assembly Language Considerations"->"Calling Conventions.."

Paul K. McKneely

unread,
Dec 21, 2011, 2:48:35 PM12/21/11
to

> Not sure why you are using a wikipedia article instead of the OW
> documentation available. If you havn't done so please take a look into
> the "Open Watcom 1.9 C/C++ User's Guide Help" around/below the
> chapter "32-bit Assembly Language Considerations"->"Calling Conventions.."

The User's Guide says that, when passing arguments on the stack, the called
function is responsible for removing the arguments from the stack. I
compiled some test code and verified that this statement is false. The
caller does indeed clean the arguments from the stack that it put there. In
fact, I have written and have been using hundreds of assembly functions for
many years and all of them expect the caller to clean up whatever it put on
the stack. They work. If what I read in the User's Guide were true, then
printf could not have a variable argument list, but it must or it would be a
useless function.

Also, the User's Guide says that EAX is the only register that should not be
saved. I know this is also false because EDX is used to return the
high-order half of a 64bit value and SI is used to return pointers. I have
also read elsewhere that ECX is not protected. The Wikipedia article seems
to give more correct information than does the Open Watcom User's Guide. :(


Steven Levine

unread,
Dec 22, 2011, 2:10:49 AM12/22/11
to
On Wed, 21 Dec 2011 19:48:35 UTC, "Paul K. McKneely"
<pkmck...@sbcglobal.net> wrote:

Hi,

> The User's Guide says that, when passing arguments on the stack, the called
> function is responsible for removing the arguments from the stack.

Not in my copy of the docs. At least not where I expect find this
documented. Where did you read this?

>The
> caller does indeed clean the arguments from the stack that it put there.

And your point is? What compiler options did you use and what version
of the compiler? You do realize that OpenWatcom supports a large
number of calling conventions and the defaults have changed over time.

I assure you that any number of us can build a -6r testcase that shows
the callee removing the arguments from the stack.

> Also, the User's Guide says that EAX is the only register that should not be
> saved. I know this is also false because EDX is used to return the
> high-order half of a 64bit value and SI is used to return pointers. I have
> also read elsewhere that ECX is not protected. The Wikipedia article seems
> to give more correct information than does the Open Watcom User's Guide. :(

If you wish to be part of the solution, you need to indicate exactly
where you read this in the docs. No one can read your mind and
documentation errors do occur.

BTW, if you wish to use Wikipedia as your Open Watcom User's Guide, go
right ahead. Freedom of choice is a good thing.

Steven

--
---------------------------------------------------------------------
Steven Levine <ste...@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------

Paul K. McKneely

unread,
Dec 22, 2011, 11:31:10 AM12/22/11
to
> Not in my copy of the docs. At least not where I expect find this
> documented. Where did you read this?

The following statement was taken directly from the Open Watcom 1.9 online
help documentation User's Guide in the follow section:
32-bit Assembly Language Considerations
32-bit: Calling Conventions for 80x87-based Applications
32-bit: Passing Values in 80x87-based Applications

<<<<<<<<<<<<<<<< Begin Except >>>>>>>>>>>>>>>>>>>>
Any assembly language function must obey the following rule.

1. All arguments passed on the stack must be removed by the called function.

<<<<<<<<<<<<<<<< End Exceprt >>>>>>>>>>>>>>>>>>>>

Since the processor I am using (AMD Phenom II Quad Core on Windows 7)
has an integrated FPU, I am assuming that the (80x87-based Applications)
applies here and that non-80x87 is for 386-based systems with no FPU
(i.e. floating point operations implemented with integer-only run-time
libraries).

> What compiler options did you use and what version of the compiler?

Open Watcom C/C++ Compiler 1.9, 386 Stack-based Calling option

As far as the protected regsiter issue is concerned, I reread it and I think
I just mis-understood something it said. Seems that EAX, ECX, EDX and
probably ESI do not have to be protected. All others do.


Paul S. Person

unread,
Dec 22, 2011, 12:49:35 PM12/22/11
to
The section
>32-bit Assembly Language Considerations
>32-bit: Calling Conventions for 80x87-based Applications
itself has this to say:

1. If the argument is not floating-point, use the procedure
described earlier in this chapter.

so, unless /all/ your arguments are floating-point, the statement you
quoted only applies to some of them.

There is an awful lot of ... stuff ... described "earlier in this
chapter". One bit that might be relevent is on
32-bit: Interfacing to Assembly Language Functions
and reads:
2. All used 80x86 registers must be saved on entry and restored
on exit except those used to pass arguments and return values, and AX,
which is considered a stratch register. Note that segment registers
only have to saved and restored if you are compiling your application
with the "r" option.
among many other notes. (That "stratch" should, of course, be
"scratch"). But there are a lot of sections before and after this one
that might be relevant or otherwise useful.

So, the 80x87 section is concerned with ... values intended for the
80x87. This should hardly be surprising. For a general answer you
probably should review the general sections on this topic. Enjoy!
--
"'If God foreknew that this would happen,
it will happen.'"

Wilton Helm

unread,
Jan 6, 2012, 2:50:53 PM1/6/12
to
The Pascal convention expects the called function to clean the stack. The
normal C convention expects the caller to do so. Which convention is chosen
makes a big difference. And no, an 8087-based application is not one
running on a CPU with integrated coprocessor. It has to do with the
convention chosen and the variables passed. Such a CPU can run code just
fine that ignores the co-processor. The compiler wouldn't know. As others
have stated, it is probably necessary to read the whole section carefully to
understand when each convention come into play. That's the beauty of high
level languages, they hide such details. Those of us who chose to dive into
assembly bear the responsibility of digesting a whole additional set of
specifications.

Wilton




0 new messages