pruss@ria.ccs.uwo.ca (Alex Pruss) (08/10/90)
In article <1162@zeus.irc.usq.oz> is written: >My references have primarily been: > >Stevens, Al "TurboC - Memory-Resident Utilities, Screen I/O and > Programming Techniques" > >Hyman, Michael "Advanced DOS - Memory-Resident Utilities, Interrupts > and Disk Management with MS and PC-DOS" > >Simrin, Steven "The Waite Group's MS-DOS Bible 3rd Ed." You should always have with you: 1. IBM Technical Reference Guide or another BIOS disassebly 2. Inter290 interrupt list Enough said, let's go on. >PROBLEM > >The resultant program basically works but is intermittently unstable >(i.e. crashes, jumping off to all regions of memory). This degree of >stability has been achieved after hacking some of the TC-compiled assembler >code (to make it smaller, use RET 2 at the end of the disk interrupt >to preserve registers etc etc). Now, wait... What do you mean to preserve registers? If you declare a function as interrupt, the registers will be OK. If you mean not to overwrite the flags, it is better (i.e. pure C code), to declare as an interrupt\ routine, then do a lahf (which you could even do via an emit) followed by flags=_AX; I have a lot of experience with writing int handlers in C. What I've noticed is that it is necessary usually to go to assembly. Anyways, here are some thoughts of mine: 1. do you make sure that either: a. by the time the next timer tick comes in, your handler is finished (you only have a 1/18.2 second slot). b. you send a specific/nonspecific EOI (I'd go for specific, but IBM's BIOS goes for nonspecific) as soon as possible (nonspecific EOI is outportb(0x20,0x20). 2. you do not reenter MesS-DOS (exception: safe reentry after swapping the three DOS stacks--see int 21/ AX=560B? in inter290). >SOME THOUGHTS > >Does anyone know of the reentrancy status of TurboC code/subroutines - >I mean more than whether DOS or BIOS routines are used? Are there any >sneaky stack swaps or something anywhere? Hmm.... I haven't got library source. I would think they are almost always reentrant... What routines do you use? I almost NEVER call TC routines from within an interrupt handler. But, I do think most things are reentrant. Ah! Wait! Floating point code is not reentrant! (Turbo C does not do a software stack-extend) Especially if you use the fp emulator and not a real coprocessor. (8087 programs are sort-of-reentrant, but the stack is only 6 numbers long). Also any routines that `return a pointer to a static area' are probably not reentrant (e.g. get password routine). >Are BIOS routines reentrant? Most of them. Of course if you reenter the disk routines in the middle of the DMA setup, you're screwed. It should be fine, however, to reenter while disk is running... maybe. I would check the disk motor status before calling a disk routine. >Any comments AAARRRGGGHHH!!!! (emotive cry of desparation), anything at >all, with regard to this problem, the references I have cited, something >I am likely to have missed etc. etc. etc. would be appreciated. >I suspect that further email discussion would be required/appropriate. I think so too. Answer my two questions, and if necessary please send me your code. I am afraid I cannot contact the original author by email, so I am posting. Alex Pruss pruss@uwo.ca pruss@RIA.UUCP pruss@UWOVAX.BITNET [pruss@uwo.ca is preferred, the others are subject to change]
s71119@zeus.irc.usq.oz (wolfe glen) (08/10/90)
Hi MSDOS gurus, TSR writers, MSDOS "Multitaskers" writers:
HELP
BACKGROUND
I am writing a process controller intended to run under MSDos on an
PC XT compatible using TurboC V2.0. The processes are all rather slow
and so processing each of them takes some time.
PROJECT
To enable changing setpoint values etc etc, I have redirected the keyboard
interrupt (int 0x9) to set a flag so that a command parser can be started
by the clock interrupt (int 0x8 rather than 0x1c for reentrancy problems).
This approach has been used to allow later modification to allow set
point control/interrogation by means of a COM: port.
I have treated the problem as a TSR without exiting the spawning program.
My references have primarily been:
Stevens, Al "TurboC - Memory-Resident Utilities, Screen I/O and
Programming Techniques"
Hyman, Michael "Advanced DOS - Memory-Resident Utilities, Interrupts
and Disk Management with MS and PC-DOS"
Simrin, Steven "The Waite Group's MS-DOS Bible 3rd Ed."
PROBLEM
The resultant program basically works but is intermittently unstable
(i.e. crashes, jumping off to all regions of memory). This degree of
stability has been achieved after hacking some of the TC-compiled assembler
code (to make it smaller, use RET 2 at the end of the disk interrupt
to preserve registers etc etc).
SOME THOUGHTS
Does anyone know of the reentrancy status of TurboC code/subroutines -
I mean more than whether DOS or BIOS routines are used? Are there any
sneaky stack swaps or something anywhere?
Are BIOS routines reentrant?
Any comments AAARRRGGGHHH!!!! (emotive cry of desparation), anything at
all, with regard to this problem, the references I have cited, something
I am likely to have missed etc. etc. etc. would be appreciated.
I suspect that further email discussion would be required/appropriate.
Thanks for reading.