SM>  *** Glen McNabb wrote in a message to Scott McNay:
SM> GM> I was thinking it didn't make a difference to an 8088/188...
SM> GM> it would take the same time either way... (you did list
SM> GM> those) but, I could be wrong too.
SM> Well, that IS the point, after all, since you're wanting to distinguish 
SM> chips with 16-bit data buses from 8-bit data buses with this code.  Or, 
SM> if you work with double-word boundaries, you can distinguish 
SM> 386SX/486SLC/486BL from 386DX/486DX/486SX.
I wasn't trying to be picky... It's just on an 8088/80188 it takes longer
to read across the even boundry when reading 16 but, not 8 bits.
That's all. :)
SM> SM> SM> On the 808x, when loading SS, an interrupt can occur before SP is 
SM> SM> loaded, 
SM> SM> GM> Reliably, a well written interrupt will not use the current
SM> SM> GM> stack for that reason.
SM> SM> You must be talking about something else...  it sounds like you're 
SM> SM> talking about stack overflow.  In this case, for reliability, you'd 
Not really, it's just that the location of the stack is undefined.
One of the reason for changing stacks has to do with TSR's. If it's a COM
TSR you would want to reduce the memory requirement before de-allocating
memory. One way is to move the stack closer to the psp. If your TSR isn't
going to use the psp (such as a pop clock) it could be moved there.
SM> GM> as possible, check the DMA count is high enough before you
SM> GM> do. It's really important for interupt routines in a
SM> GM> multitasking environment...
SM> DMA count?  Can you elaborate on this?
I'm sorry, I was thinking of something else... (a brain fart)
related to refresh... nothing to do with this...
The main thing is to CLI before and STI afterwards.
SM> Personally, I'd not change stacks at all, if I could help it, and trust 
SM> that the application program set aside enough memory to handle my 
SM> handler's requirements, and also perhaps, if I were really paranoid, I'd 
SM> pull my data off the stack and store it into an internal data structure.
That's great for assembled COM programs. When writing an object or EXE it's
another matter.
One method of determining "enough" stack space is to allocate stack space as
db 100 dup "STACK" (make it oversized). Then run the program through debug.
When it's done, then do dump of the whole stack space and see how much is
used during run-time. (how much STACK is overwritten) This can give you
a rough idea of how much stack space is used...
SM> Of course, I could just ASSUME a PC-compatible board, and disable NMI.
You can't disable the NMI. It's hardwired to the parity check. The port to
disable the parity on motherboards vary from one make to the next. If your
writing for yourself, that's ok, a market item is just about impossible.
The most you can do is either CLI or disable the PIC chip(s).
SM> Since 808x CPUs are rarely seen nowadays, I don't think I'd bother to go 
SM> out of my way, though, unless I already needed code to control NMI, in 
SM> which case, might as well use it.
The hardest thing I ever tried to do was write an interupt to chain into
the int-16 in a multitasking environment. I was stuffing keys into a
program that I shelled as a child process. Needless to say, it was a
real learning experience... (suffered mucho crashes)
Glen...
--- ProBoard v2.16 [Reg]
---------------