Re: keyboard/mouse programming

On Dec 2, 12:38 pm, "Rod Pemberton" <do_not_h...@xxxxxxxxxxxxx> wrote:
<s_dubrov...@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)

Well yes, we are on the same page here esp. if 4) is stored on the
stack frame.


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...)

AFAIK, static & global are handled as stored in .data_segment. (if no
external linkage) Now, remember, I'm not after a full blown C++
compiler, but a small-c compiler, used as an aid, to compile, what is
better thought of as, C psuedo code. Just a small HLL helper to do
some byte banging for my hobby os.

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...

Right.

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...

Exactly, you can pusha for about the time price of pushing 2 regs, so
why not.
Well, my hobby os is targeted for what I have around, meaning <= win98
or XP era gear, as a possible replacement for those os's. If I can
get to something fuctionally equivalent without some of the bugs, I'd
consider that a great success. The old gear may be around long enough
for me to do it. But the time I get close, the new gear won't allow
loading such stuff due to DRM or built in 'security features'.

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-w...

"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...
I'm more concerned that acceptance of an ABI design too early would
drive the design of the hobby os. If I concede here, I might as well
give up, adopt current HLL tools and build yaunix. (yet another
unix.)

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);

Parameter x, passed on the stack, is returned on the stack. Not
passed y, is returned .. where .. exactly? -is the Q, you say next...

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...

Really? I've more research to do, see I'm not a C guru. Then, there
is no issue. Return (n) in .n.'s placement on the stack. However,
suppose I want to do something un C like and return to the caller some
non scalar type as a result of being called without any parameter. --
another vote for asm then.

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...


Well my thought was to push a last parameter as a place for a return
value for a function call.

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/...

Anyway, good luck.

Rod Pemberton
Thxs,
Steve

.

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 ... "cdecl" calling convention is what's normally used for C on x86. ... "stdcall" is what is normally used for Windows, ...
    (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: keyboard/mouse programming
    ... But register values make a subroutine non- ... All versions of C I'm aware of do this using a stackframe. ... structures, unions, etc. in eax. ... parameters don't need to be copied or pushed onto the stack since they are ...
    (alt.lang.asm)
  • Re: Accessing the CALL STACK
    ... > The StackTrace/StackFrame class is the way that you would access call ... Getting the call stack is ... I am hooking into the XmlDocument nodechanged event, ... >> StackFrame stackFrame; ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: va_list zusammenbasteln fuer vfprintf?
    ... der Compiler die Parameter von hinten auf den Stack pushd: ... {// Struktur, die einem Stackframe entspricht ... // jetzt die Parameter aufbauen ... Das ganze kann so nicht funktionieren. ...
    (de.comp.lang.c)