LINDAHL@brandeis.BITNET (01/19/87)
Date: Sun, 18 Jan 87 23:38 EST
From: <LINDAHL@BRANDEIS.BITNET>
Subject: GEMDOS memory allocation
To: info-atari16@score.stanford.edu
X-Original-To: info-atari16@score.stanford.edu, LINDAHL
has anyone looked into the way that GEMDOS manages memory? i seem to lose
RAM over time, especially after running programs like micro emacs which
do lots of Malloc calls (you are only allowed to allocate 20 blocks per
process according to the GEMDOS manual). i think that GEMDOS "loses" memory
when you do too many Mallocs, so i would like to look at the memory free
and memory allocated lists and see what blocks aren't on either list.
i looked into the Getmpb() bios function, but it seems that as far as the
bios is concerned, GEMDOS allocates all memory. obviously GEMDOS is
managing this memory internally.
i next tried to trace a Malloc() call using MonST in trace-walk mode,
but my machine freezes up when the rom routine tries to change register a7.
(i guess that MonST isn't preserving it's stack or something.) no doubt the
answer lies in the rom somewhere, but i'd rather spend lots of time looking.
does anyone have any idea where GEMDOS keeps its list?
Greg Lindahl
us snail: box 2522 brandeis university bitnet: lindahl@brandeis.bitnet
waltham mass 02254 cps: [76515,1122]
[NSA CIA Cray hackey-sack tie-dye divestment radical civil disobedience
Thoreau Locke Hobbes flower-power frisbee physics star wars Teller
long hair vegetarians 'and to think that MY tax dollars pay for this!']apratt@atari.UUCP (Allan Pratt) (01/20/87)
*** FLAME ON *** > has anyone looked into the way that GEMDOS manages memory? > ... > does anyone have any idea where GEMDOS keeps its list? PLEASE don't go around publishing internal addresses like this requests, since such addresses are GUARANTEED to change and BREAK programs which count on them. Some parts of an operating system are hidden from view ON PURPOSE, so the OS can be sure that its data structures will not be fooled with by user programs. The correct procedure in this kind of situation is to say, "Gee, Atari, I lose memory over time.. I wonder if there's a problem in the memory allocator? Here is an example program which demonstrates the problem..." I know we won't always have a fix for the problem by next week, but f**king around with GEMDOS' internal structures will cause more trouble than it's worth. *** FLAME OFF *** As it happens, we know that memory gets fragmented strangely, and the limit on memory blocks you can Malloc is a function of statically-allocated data structures. In future ROMs, we may increase the limit, but we can't get rid of it without a new, more fragile memory allocator (one which assumes that you haven't changed memory locations immediately before and after blocks you allocated). /----------------------------------------------\ | Opinions expressed above do not necessarily | -- Allan Pratt, Atari Corp. | reflect those of Atari Corp. or anyone else. | ...lll-lcc!atari!apratt \----------------------------------------------/
fouts@orville (Marty Fouts) (01/21/87)
In article <525@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >*** FLAME ON *** > >> has anyone looked into the way that GEMDOS manages memory? >> ... >> does anyone have any idea where GEMDOS keeps its list? > >PLEASE don't go around publishing internal addresses like this requests, > ... >The correct procedure in this kind of situation is to say, "Gee, Atari, > ... >I know we won't always have a fix for the problem by next week, but >f**king around with GEMDOS' internal structures will cause more trouble >than it's worth. > >*** FLAME OFF *** > Get Real Alan. Although I agree that programs should not muck with undocumented internal structures, real users have to make the trade off between something which works now but breaks later and something that's broken now but will work someday. If the only workaround is to hack internal data structures, than hack the data structures, and document what you did. I the user will decide which course I want to take. *** FLAME ON *** Putting operating systems into ROM puts the onus of responsive bug fixing on the vendor in a major way. I suspect that Atari is giving very low priority to fixing existing bugs in order to get new products out. This is not how you meet the onus nor is it how you establish repeat customers. There are currently many 'well known' bugs in the ST software and no sign of a ROM upgrade. I stand unimpressed, and unlikely to be a repeat customer regardless of the wiziness of any new product offering. *** FLAME OFF ***
manis@ubc-cs.UUCP (01/23/87)
In article <186@ames.UUCP> fouts@orville.UUCP (Marty Fouts) writes, in response to remarks by Allan Pratt of Atari: >Get Real Alan. I'm not sure how real he has to get. Obviously Atari has vested interests in keeping undocumented features undocumented; this lets them change them later. Given the generally low quality of the DRI software in the ST, they have good reasons for wanting to change much of it. However, I as a consumer, have just as good reasons for wanting programs not to depend upon undocumented features. If those features are changed, then suddenly programs don't work. Ask anybody in the IBM PC world about the disadvantages of bypassing the BIOS in order to make the program run faster. Backward and forward compatibility are essential if the ST is to continue to flower. There's an enormous amount of PD software available for the machine, and some of it is really good. If programs start malfunctioning (say by accidentally trashing a device control block that now lives where some Malloc parameters used to live), people will stop using (and therefore stop writing) PD software. If programmers start depending upon undocumented features, they will force Atari to support those features. Is that more important than having them rewrite GEMDOS so it works? What I want is for Atari to fix bugs, even at the cost of changing data structures. Allan (and Landon and Neil) have offered to give good workarounds if we can formulate the bug reports properly. Let's take them up on it.