From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 10891a,99a64c15f8d0157e X-Google-Attributes: gid10891a,public X-Google-Thread: 103376,99a64c15f8d0157e X-Google-Attributes: gid103376,public From: Greg Bond Subject: Re: GNAT and interrupts with DJGPP and CWSPR0 Date: 1996/08/16 Message-ID: <3214FB21.6A9A@ee.ubc.ca> X-Deja-AN: 174659426 references: <32110129.3C6E@ee.ubc.ca> to: Jerry van Dijk content-type: text/plain; charset=us-ascii organization: Dept. of Electrical Eng., UBC mime-version: 1.0 newsgroups: comp.lang.ada,comp.os.msdos.djgpp x-mailer: Mozilla 2.02 (Macintosh; I; PPC) Date: 1996-08-16T00:00:00+00:00 List-Id: Jerry, Thanks for your reply. I've scanned the archives of both the Ada and DJGPP newsgroups and you seem to be the only guy that's doing low level programming with GNAT using DJGPP. I'm new to DJGPP, and new to the concept of a DPMI server in particular. For this reason I've got a couple of questions regarding your reply. Greg Bond wrote: > > Jerry van Dijk wrote: > > I'm not sure whether this will go out... > > Greg Bond (bond@ee.ubc.ca) wrote: > > : Since I'm using CWSPR0 (a ring 0, no frills DPMI server that disables > : virtual memory) > > This solves the problem of not being able to lock all memory used by > the interrupt handler, but still leaves the problem of real mode interrupt > defection by DPMI, if you access the first megabyte. What do you mean by "real mode interrupt detection"? Is this when, say, a clock interrupt occurs and calls a DOS-installed interrupt handler? How would the DPMI server be able to distinguish between a DOS-installed, real-mode handler, and a DJGPP installed, protected-mode handler? > > I believe I still might be able to access memory > : locations directly (anyone know enough to disagree?). > > Accessing memory locations directly will work anyway by using the djgpp > library. Yes, but I want to keep the program as Ada as possible i.e. I want to avoid using the foreign language interface whenever possible. I want to do this for a couple of reasons. I'm teaching Ada as part of a course in real-time programming and I want to illustrate the "support" Ada has for system programming. With any luck, the embedded assembly stuff and interrupts will be supported in the next GNAT release before I teach the course again. The other reason is that I'm working on an embedded 80x86 port of GNAT which will not require a DPMI server. For this reason I'm trying to determine how a program can be written that avoids using the DPMI server wherever possible. > : So my thought was > : that I could install a (mostly) Ada interrupt handler in Ada using the > : 'for', 'use' keywords to assign an address to the interrupt handler. > > Yep, in theory this should work, if you tell GNAT that this is a callback > function (so its C-style callable). However, you run into problems if you > try to use arguments. And don't forget using the right stack :-) Why should the Ada interrupt handler be C-style callable? Is this because the DPMI server intercepts the interrupt and then calls the Ada handler? Regarding the "right stack": I take it that interrupts are handled on a supervisor stack? This would definitely interfere with the interrupt task design I mention below. > : Since I've got to include some assembly language in the handler itself, > : I could use the Ada handler as a wrapper to call a C/assembly handler > : via Ada's foreign language interface. > > If that's the case, why not write the whole handler in C ? As I mentioned above, I want to avoid using the foreign language interface whenever possible. > : The design I have in mind is to have an Ada interrupt task wait on a > : guarded entry of a protected object for interrupt events (the > : recommended way of handling interrupts in GNAT). > > Oops, that changes things a bit. I'm not sure how interrupt safe the DOS > port of pthreads really is.... Me either.... My guess is that this isn't going to work (sigh...!) The only alternative is using Ada tasks that poll for flags to be set by the interrupt handler, or using Ada tasks to poll the hardware directly....yuck! > : If it won't work, what > : are my alternatives? The only alternative I can think of is polling the > : hardware directly from the interrupt task > > This depends on what you are trying to archive. And the interrupt frequency > you are looking at. I've got a periodic serial port interrupt occurring approx every 100ms, and an aperiodic interrupt from the parallel port occurring with a max. event density of 1 event per 200ms. I've also got a timer interrupt going off every 100ms but this is being handled by the GNAT run-time (via the DPMI server I assume) since the Ada "delay until" keyword is used to set it up. Greg. -- * Greg Bond * Dept. of Electrical Eng. * email: bond@ee.ubc.ca * Univ. of British Columbia * voice: (604) 822 0899 * 2356 Main Mall * fax: (604) 822 5949 * Vancouver, BC * web: http://www.ee.ubc.ca/~bond * Canada, V6T 1Z4