Date: Tue, 25 May 1999 10:43:41 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Shawn Hargreaves cc: djgpp-workers AT delorie DOT com Subject: Re: gcc 3.0 In-Reply-To: <19990524203918.I11359@talula.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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." >