Mail Archives: djgpp-workers/1999/05/25/04:57:33
On Mon, 24 May 1999, Shawn Hargreaves wrote:
> I don't see why this couldn't be done, but my worry is that it might not
> actually be all that useful. As I found when experimenting with Watcom, the
> wrapper is really the easy part of writing an IRQ handler, and when a
> compiler tries to automate this, it is liable to actually end up just
> confusing people more because some of the problems are hidden where you
> can't easily get at them.
My suggestion was meant to be a replacement for the mandatory use of
the library wrappers. I think saying "#pragma interrupt" is easier
than throwing in all the code to call the wrapper (which everybody
probably cut-and-pastes from either the FAQ or some other tutorial
anyway).
Whatever cannot be done by using the wrappers will continue to need
custom interrupt handlers, exactly like using the interrupt keyword
leaves some interesting things unaccounted for. People who need this
will simply not use #pragma interrupt as they don't use the wrappers
today.
> I do have some reservations about how the libc interrupt wrappers currently
> work
May I suggest to submit changes to the wrappers, then?
> Also, the libc handlers only
> allocate one stack per interrupt, which makes it impossible to do anything
> but crash if a reentrant interrupt comes along.
Sorry, I'm not sure I understand this completely. If the stack is
large enough, why are reentrant interrupts a problem, exactly?
> I don't think there is any really generic solution to this, though, because
> everyone has different needs.
Perhaps we could have several solutions for several popular needs.
> For the Allegro wrappers, I allocate several
> stacks in the startup code, and then search for a free one whenever a
> handler is triggered, which fixes the reentrancy problem, but adds a lot of
> overhead (64k of locked memory) that wouldn't be acceptable in a less
> hardware-oriented program. It is impossible to guess how many stacks will be
> needed, and how big they need to be, without knowing how much code people
> are planning to run inside the handler...
This seems to be solvable by having the application define compile-time
constant variables that request specific number and size of the
stack(s), like _stklen does.
> Sorry, what does WIBNI mean?
Wouldn't It Be Nice If.
> I'm no expert on the linker script format, but I think something like this
> would do the trick:
Thanks.
Would people please look at this and see if it is okay? If so, I
think we could add it to a future release.
> In a header somewhere:
>
> #define __DJGPP_LOCK_CODE__ __attribute__ ((section ("locktext")))
> #define __DJGPP_LOCK_DATA__ __attribute__ ((section ("lockdata")))
>
>
> In djgpp/src/libc/crt0/_main.c, just before it calls the constructors:
>
> extern char djgpp_first_locktext[] __asm__ ("djgpp_first_locktext");
> extern char djgpp_last_locktext[] __asm__ ("djgpp_last_locktext" );
> extern char djgpp_first_lockdata[] __asm__ ("djgpp_first_lockdata");
> extern char djgpp_last_lockdata[] __asm__ ("djgpp_last_lockdata ");
>
> if (djgpp_first_locktext < djgpp_last_locktext)
> _go32_dpmi_lock_code(djgpp_first_locktext, djgpp_last_locktext - djgpp_first_locktext);
>
> if (djgpp_first_lockdata < djgpp_last_lockdata)
> _go32_dpmi_lock_data(djgpp_first_lockdata, djgpp_last_lockdata - djgpp_first_lockdata);
>
>
> And use the replacement djgpp.djl that I've attached. This allows a function
> to be locked just by writing a prototype in the form:
>
> void myfunc() __DJGPP_LOCK_CODE__;
>
> and a variable by doing:
>
> int flag __DJGPP_LOCK_DATA__;
> int inited_flag __DJGPP_LOCK_DATA__ = 42;
>
>
> I haven't tested it in great detail, but it seems to work correctly. As I've
> currently done it, uninitialised locked globals will be output into the data
> section, bloating the executable. This could be avoided by adding a third
> section for locked bss data, but then people would have to remember which
> type of macro to use when they declare it, and I'm willing to bet we'd have
> problems with people getting confused and putting initialised data into the
> bss section by mistake...
>
>
>
>
> --
> Shawn Hargreaves - shawn AT talula DOT demon DOT co DOT uk - http://www.talula.demon.co.uk/
> "A binary is barely software: it's more like hardware on a floppy disk."
>
- Raw text -