Can IRQ exceptions malloc memory ? (&using IPL7)

Can IRQ exceptions malloc memory ? (&using IPL7)

Post by 89189.. » Fri, 16 Oct 1992 09:10:18



Gday
        On the subject of TSR's malloc'ing memory - can hardware interrupt
exceptions in supervisor mode also malloc memory ?.. I'm trying to get a
exception routine working that calls a Lattice 5.06.01 malloc call (in
the library, but gets bus errors half way through...).. Should I be
calling gemdos directly via a trap ?

        And - also is it safe to use IPL7 for hardware interrupts ?? -
or should I use IPL5 (I'm using an Atari MEGA ST)

Thanks
Kym
------------------------------------------------------------------------------
   "`Get back' I screamed, `I'm an Australian!'.I new this was a pretty
   lame excuse and prepared myself for the truth. `Australia is merely an
   Island of Antarctica' came the voice,`and of no further significance.'
               Suddenly I understood the secret of Atlantis."
--`What's Rangoon to you is Grafton to me' by Russell Guy. JJJ-FM circa 1978--

 
 
 

Can IRQ exceptions malloc memory ? (&using IPL7)

Post by Steven Ek » Sat, 17 Oct 1992 18:03:28


|> Gday
|>   On the subject of TSR's malloc'ing memory - can hardware interrupt
|> exceptions in supervisor mode also malloc memory ?.. I'm trying to get a
|> exception routine working that calls a Lattice 5.06.01 malloc call (in
|> the library, but gets bus errors half way through...).. Should I be
|> calling gemdos directly via a trap ?
|>

Memory management routines, whether is TOS or in libc usually modify global
data structures (free lists etc) which makes them non-reenterant - ie you
can't safely call them from interrupts. When I needed a malloc/free that
was callable both from interrupt code & normal code I ended up writing my
own in asm.

|>   And - also is it safe to use IPL7 for hardware interrupts ?? -
|> or should I use IPL5 (I'm using an Atari MEGA ST)

You can set IPL to want you want providing:

If you access hardware registers/TOS variables you want it high enough
so that you don't get interrupted by a TOS routine using the same registers/
variables. The classic example is the Yamaha sound chip - you need to
be at IPL 7 to ensure the selectedregister number doesn't change between you
setting it & writing to the selected register.

Your interrupt code must not have the IPL too high for too long so that
other high priority interrupt don't run on time. At IPL 7 nothing else runs
and the MIDI port can overrun in 320uS so stick to below 300uS (Atari themselves
screwed up here - they actually recommend a 1mS limit).
At IPL 5 all the MFP stuff can interrupt you* but VBI stuff is blocked so stick
below about 10mS and you should be OK.

*Assuming your routine isn't MFP OR the MFP interrupt is higher priority than
yours OR you've cleared your interrupt-in-service bit on the MFP chip.

Steven

 
 
 

Can IRQ exceptions malloc memory ? (&using IPL7)

Post by Eric Smi » Sun, 18 Oct 1992 06:36:28



>    On the subject of TSR's malloc'ing memory - can hardware interrupt
> exceptions in supervisor mode also malloc memory ?.. I'm trying to get a
> exception routine working that calls a Lattice 5.06.01 malloc call (in
> the library, but gets bus errors half way through...).. Should I be
> calling gemdos directly via a trap ?

No kind of interrupt routine should ever try to make a GEMDOS system
call (including Malloc), because GEMDOS is not re-entrant. Since most
library malloc() calls eventaully call the GEMDOS Malloc(), this
means you'll have to roll your own memory allocation (probably by
allocating a big chunk of memory before your program installs itself
as a TSR, and managing that memory yourself).
--
Eric R. Smith                     email:

University of Western Ontario
 
 
 

Can IRQ exceptions malloc memory ? (&using IPL7)

Post by Patrick BETREMIE » Mon, 19 Oct 1992 05:57:01



>    On the subject of TSR's malloc'ing memory - can hardware interrupt
> exceptions in supervisor mode also malloc memory ?.. I'm trying to get a
> exception routine working that calls a Lattice 5.06.01 malloc call (in
> the library, but gets bus errors half way through...).. Should I be
> calling gemdos directly via a trap ?

ARGH. Never malloc memeory unless you are the current GEMDOS process.
Why? Simply because TOS always mallocs the space for the last program called
with exec(). If you malloc() some, and the current program terminates, your
memory will get deallocated automatically, and you wouldn't know it.
Which means terrible effects could happen if let's say, GEM decides to
get some itself for a huge .rsc file, and you decide to write to it !!!

TSR's should rely exclusively on what they start with.

                                        Patrick.

 
 
 

Can IRQ exceptions malloc memory ? (&using IPL7)

Post by mj.. » Tue, 20 Oct 1992 20:02:41




>>        On the subject of TSR's malloc'ing memory - can hardware interrupt
>> exceptions in supervisor mode also malloc memory ?.. I'm trying to get a
>> exception routine working that calls a Lattice 5.06.01 malloc call (in
>> the library, but gets bus errors half way through...).. Should I be
>> calling gemdos directly via a trap ?

>ARGH. Never malloc memeory unless you are the current GEMDOS process.
>Why? Simply because TOS always mallocs the space for the last program called
>with exec(). If you malloc() some, and the current program terminates, your
>memory will get deallocated automatically, and you wouldn't know it.
>Which means terrible effects could happen if let's say, GEM decides to
>get some itself for a huge .rsc file, and you decide to write to it !!!
>TSR's should rely exclusively on what they start with.

All true and good advice, but it's worse than that.

You should never call GEMDOS from an interrupt because GEMDOS is not
re-entrant. This means that it cannot support two processes calling it at
once.

Imagine if the main application is in the middle of some GEMDOS call when
your hardware interrupt comes along. Control is passed to your handler,
which calls GEMDOS... bang.

Quote:>                                    Patrick.

Mat

| Mathew Lodge                      | "A conversation with you, Baldrick,     |

| Langwith College, Uni of York, UK |  -- Blackadder II                       |

 
 
 

1. MWC malloc and Malloc

I previously mentioned that the size of each Malloc can be
adjusted in MWC so that repeated calls to malloc won't run
out of memory.  Here is a code fragment from STEVIE.

bool_t
readfile(fname,fromp,nochangename)
char    *fname;
LPTR    *fromp;
bool_t  nochangename;   /* if TRUE, don't change the Filename */
{

/* HERE IS THE MAGIC PARAMETER */
        extern long     _aclicksize;            /* malloc granularity   */
        struct stat xstat;
        long    l;

        if(stat(fixname(fname),&xstat) < 0) {
                fprintf(stderr,"Cannot open %s ???\n",fixname(fname));
        }
/* xstat contains the info on the file fname */
        l =  xstat.st_size/_aclicksize;
        if( l > 32) {
                _aclicksize =  (_aclicksize /32) * l ;
        }
---------
In this program only this module does malloc() calls.
Thus by guaranteeing that there will be no more than 32 Malloc() calls to
TOS all is well.
----------

Howard C. Johnson
ATT Bell Labs
=====NEW address====
att!lzsc!hcj

2. INFO NEEDED on VIRUSES

3. malloc bugs (s.b. Malloc bugs)

4. Automatic ssh key installer available (fwd)

5. Malloc(-1L), free memory...

6. Looking to purchase gold Cdr's

7. MWC malloc and memory upgrade

8. Good CAD package(s) for Linux??

9. 5200 & Intel & 800 & TI & Coleco & CoCo & Vic games 4 sale!

10. Is there a fix for malloc difference between TOS1.6 & 2.05?

11. New & Used Software & Hardware

12. F030 BLiTTER IRQ

13. timing-routine / IRQ