Re: keyboard/mouse programming


<s_dubrovich@xxxxxxxxx> wrote in message
news:8e988419-7afb-48ce-9ce7-f5a7057264cb@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Yes, register variables are problematic for reentrant function calls
(a function which calls itself, or, round-aboutly ends up calling
itself).
"If a function in a C program uses only auto variables, it will be
reentrant."

In C, use of these should be reentrant:
1) procedure local auto variables (created in a new stackframe each time)
2) parameters passed to the procedure (copied from old stackframe each
time)
3) parameters returned to the calling procedure via pointer (copied into
the old stackframe)
4) return passed out of the procedure (saved usu. via cpu register)

(NOTE: both 3) and 4) return values... i.e., you could place the return into
the stackframe)

In C, use of these won't be reentrant:
1) variables with file scope (i.e. "global" - these only have a single
location for storage and will be overwritten)
2) static variables (I don't use these, so not sure how these work...
Chuck? They probably have a single location for storage...)
3) register variables (will be corrupted upon change to same register)
4) longjmp et. al. (corrupts cpu registers and/or destroys current
stackframe...)

"Any functions in a C program that are used by the interrupt handler
should be made reentrant." -'Real-Time Microcomputer System Design: An
Introduction' by Peter D. Lawrence and Konrad Mauch.


That means don't use file scope variables, static variables, register
variables, or longjmp in a C function used in an interrupt.

Third, the ABI I was looking at is abi386-4.pdf, System V,
conveniently ref'd. by
this wiki: http://en.wikipedia.org/wiki/X86_calling_conventions - the
wiki article also has an example of returning a return value in AX,
above and beyond the parameter activation record.


You'll probably want to search for the calling convention,e.g., cdecl or
stdcall, instead of stackframes. I've found quite a few webpages, but none
shows how parameters are returned - only the return in eax...

Anyway, "cdecl" calling convention is what's normally used for C on x86.
"stdcall" is what is normally used for Windows, except for Vista (cdecl).
"stdcall", according to the MASM 5.1 documentation, selects either "cdecl"
for variable arguments or "pascal" for fixed arguments.

Personally, I've been considering a designing a stackframe that uses pusha
and popa. This would be useful for me on ia32, but might not be so good on
aa64 due to lacking pusha, popa instructions...

Code compiled for cdecl won't be compatible with stdcall, thiscall, or
pascal due to different register usage and stackframe cleanup. Example of
problem mixing thiscall with another calling convention:
http://blogs.msdn.com/larryosterman/archive/2007/09/26/what-s-wrong-with-this-code-part-21-a-psychic-debugging-example-the-answers.aspx

"And the cdecl calling convention is possibly the worst of the x86 calling
conventions (pascal might be worse). The biggest problem with cdecl is that
the caller has to clean up the stack. When the NT kernel was changed from
being cdecl to stdcall, we literally shrunk the size of the kernel binary by
more than 10%. Code compiled with stdcall also executes faster than cdecl
because it executes fewer instructions (this may no longer be as significant
but it can add up)." - Larry Osterman
(http://blogs.msdn.com/larryosterman/archive/2004/07/20/188906.aspx)

FPO: Use of ESP instead of EBP in a stackframe (tells why cdecl is used for
Vista instead of stdcall):
http://blogs.msdn.com/larryosterman/archive/2007/03/12/fpo.aspx

I know there are options. Those options require 'considerations' as
to final ABI design which could affect, or be affected by my target
hobby os.

Ah, okay, it has to work with "junk" you didn't code...

Yes, stack frame. But now, deciding how to handle stack placement of
'return value'. Now, we have variable arguments between return|
no_return functions, and more considerations. f(x); .. return (x); is
straight forward but f(x); .. return (y); isn't, ..more
considerations.


Confused...

f(x); .. return (y);

In C, if it's not passed into a procedure as a parameter, it can't legally
be returned. Not sure that was what you meant...

Now, we have variable arguments between return|
no_return functions, and more considerations.

"variable arguments between..." Local auto variables and procedure
parameters are destroyed when the stackframe is deleted upon returning from
the function. If a parameter argument is to be passed back (i.e., passed in
as pointer) or return value returned, they must be saved in the stackframe
epilog prior to returning and deletion of the stackframe. At some point,
they have to be placed in the old stackframe. Well, I'm not completely
familiar with _all_ the details...

Recursively..but I think you see the idea of roundabout recursion..
think 'inDos Flag' also.


Ugh, 'inDos'...

I couldn't access it just now, perhaps later.
http://web.archive.org/web/20070807003824/http://cm.bell-labs.com/cm/cs/who/dmr/clcs.html

Anyway, good luck.


Rod Pemberton

.

Relevant Pages

  • Re: keyboard/mouse programming
    ... procedure local auto variables (created in a new stackframe each time) ... parameters returned to the calling procedure via pointer (copied into ... "And the cdecl calling convention is possibly the worst of the x86 calling ... the caller has to clean up the stack. ...
    (alt.lang.asm)
  • Re: Hooking to stop file move(ment)
    ... by default in C and CPP calling conversions are "cdecl" that means that the ... when stdcall is used the calling function will clean the stack. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Creating OCX at runtime crashes
    ... such as the caller thinking it is calling a __cdecl ... function and instead calling a __stdcall function, ... if it does NOT have that instruction, ...
    (microsoft.public.vc.mfc)
  • Re: mixing calling conventions question
    ... > the calling conventions: one is using stdcall and one is using cdecl. ... This would mean declaring the function types twice: ...
    (borland.public.delphi.language.basm)
  • Re: Problem: Calling an unmanaged function returning structure by value
    ... I am writing an interface for plug-ins and the application will not ... you are calling a __cdecl function however the default calling ... delegate Point Proc3; ...
    (microsoft.public.dotnet.languages.csharp)