Mail Archives: djgpp/2000/11/10/17:00:29
What happened to my post!? That's screwy...
Thanks DejaNews. :-p~
In article <9003-Fri10Nov2000120410+0200-eliz AT is DOT elta DOT co DOT il>,
djgpp AT delorie DOT com wrote:
> > From: dcasale AT my-deja DOT com
> > Newsgroups: comp.os.msdos.djgpp
> > Date: Fri, 10 Nov 2000 00:53:36 GMT
> >
> > Guess that means I need to copy my build environment to a separate
> > drive, eh? ^^;;;
>
> It would be interesting to see if this also explains the time
> slow-down...
No, that's not the cause. I was only running my program from the JAZZ
disk for about the past day or so, before I figured out what the
problem was. The slowdown's been there since the beginning.
> > > > > Why did you insert PUSHF and POPF? They are not needed for
> > > > > __dpmi_int calls; I suggest to remove them.
> > > >
> > > > Because another programmer who was working on this code before
> > > > me found that with _some_ __dpmi_int int 13h calls, interrupts
> > > > were mysteriously turned off after the call returned. That
> > > > _may_ be the reason my system clock is slowing down.
> > >
> > > Something must be turning interrupts back on, or else the keyboard
> > > would stop working as well, and you will have a totally wedged
> > > system.
> >
> > Yeah, I know. He says that the internal code for INT 21h (which I
> > also use) checks to see if interrupts are turned off, and turns
> > them back on if necessary. But, he says that if a certain error
> > condition occurs during an INT 13h call, the function jumps to a
> > spot in the return code which _misses_ the opcode to turn
> > interrupts back on.
>
> One possible cause of interupts getting subtly disabled is when you
> run a program under a debugger with CWSDPMI as your host. In this
> case, any code, including library functions, that uses __dpmi_int to
> call any of the DPMI services hooked by the DJGPP debug interface will
> return with interrupts disabled. This is because CWSDPMI implements
> the Int 31h not quite as the DPMI spec says (I forget the details).
Well, I've seen the slowdown when running a release-mode version of the
executable (with debugging printfs as necessary) with compression
turned on. Turning compression off makes the slowdown disappear.
That's why I said it was wierd.
> Note that this can only happen under a debugger, and is usually of
> concern only for programs which disable and enable interrupts.
See above.
> For the rest of this story, including some discussion, see this
> message (this URL is one long line):
>
> http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-
workers/1999/12/30/02:54:16
>
> You can browse the whole thread "Re: GDB, DOS 6.22, CWSDPMI and
> Interrupts" (posted to djgpp-workers) on DJ's server, if you want to
> know more.
Not right now, but I might look at it later. :-)
Here's an update on the situation, though. I was able to get my
compression program working with Nate Eldredge's YAMD (Yet Another
Malloc Debugger). My program has a loop which allocates some bytes,
allocates some more bytes, then deallocates both. The loop executes
without any trouble several times, then fails on an allocation.
Any ideas why that would happen? Is there a DJGPP equivalent to the
Microsoft _fheapmin call that I don't know about, that might solve this
problem?
I'll post a snippet from YAMD's symify'ed log file if you'd like, but
it's kind of large. One of the things that I noticed was that it
wasn't malloc'ing in the same spot. One time it would malloc at
0x272eff4 and 0x2732fd8 (and deallocate them both properly). The next
time it would malloc at 0x2736ff4 and 0x273afd8 (again, deallocating
them both properly). There's nothing else in between these two
allocations and deallocations in the log file, either, and they both
happen to be 12 bytes and 40 bytes. So why didn't the malloc's happen
in the same spot?
Damon Casale, damon AT WRONG DOT redshift DOT com
I'm in a heap o' trouble... ;-p
Sent via Deja.com http://www.deja.com/
Before you buy.
- Raw text -