Mail Archives: djgpp/1999/02/01/06:22:17
is05562 AT salleURL DOT edu writes:
> I've been coding some stuff with djgpp, and I've been using the
> "whole" allegro only for the keyboard handler. But I think that if
> I wrote my own keyboard handler the application I'm coding would
> be faster
I don't think that is a very sensible decision. You can surely save
a lot of space by writing something less complex than the Allegro
keyboard handler, but it won't be measurably faster. Remember that
this code is only ever executed when somebody presses a key: in the
grand scale of things this is a completely negligible overhead, and
I very much doubt that you will even see it in a profile log! There
is no point in trying to speed up your program by optimising code
that is already not taking any time to execute...
> I know I "should" lock some code/data, but as this C example
> should not swap to disk, I'm still not doing it.
It is still important, though. You might be surprised by the strange
places that some DPMI servers (eg. win95) can decide to start swapping,
and if you are running under CWSDPMI, you have to lock the data even
if your program doesn't swap (that's a safety precaution to help
people write reliable code).
> also: What's an "iret_wrapper", and "why" should I need one ? Is it
> mandatory?
Very much so. An interrupt isn't called in the same way as a regular
C function, so you need a block of wrapper code that will be called
by the hardware event, and that can then set up the standard C
environment before calling your handler function.
The djgpp libc wrappers are ok for simple interrupts, but don't
properly deal with reentrant calls to the same handler. If you need
things like that, you will have to write your own wrapper in asm:
see the irqwrap.s file from Allegro for one possible implementation
and to get an idea of what kind of stuff these wrappers must do.
> static void my_keyboard_rsi(void){
>
> asm("cli");
> leave=1;
> outportb(0x20,0x20);
> asm("sti");
> }
You don't need those cli and sti instructions. Your problem, though,
is that you are never bothering to read any data from the keyboard
controller (a byte from port 0x60), so it is stuck waiting for your
program to access the current keypress, and is unable to respond
to any further input.
Shawn Hargreaves.
- Raw text -