Path: utzoo!attcan!uunet!cbmvax!jesup
From: jesup@cbmvax.UUCP (Randell Jesup)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Task KILL for Amiga
Message-ID: <5754@cbmvax.UUCP>
Date: 23 Jan 89 07:58:59 GMT
References: <3716@crash.cts.com> <10908@s.ms.uky.edu> <5713@cbmvax.UUCP> <10926@s.ms.uky.edu> <32094@tut.cis.ohio-state.edu> <10938@s.ms.uky.edu>
Reply-To: jesup@cbmvax.UUCP (Randell Jesup)
Organization: Commodore Technology, West Chester, PA
Lines: 52

In article <10938@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes:
>In article <32094@tut.cis.ohio-state.edu> Jeff Martens <martens@cis.ohio-state.edu> writes:
>|Consider linked lists,
>|trees, etc.; to manage these sorts of structures in an application
>|program you're continuously grabbing new memory and (hopefully)
>|returning it to the system when you're done with it.

>I still say that resource allocation is an infrequently done thing. I
>use malloc(), (and brk(), and sbrk()!) on Unix just as much as the next
>guy. Just because the "better" languages encourage dynamic memory
>allocation doesn't mean it's done all the time. Yes, some applications do
>it all the time, but most do it infrequently.

	Well, if you do the same thing under amigados (using unix-clone
routines like malloc that are supplied by the compiler) you won't request
resources as often.  However, most malloc-clones don't release blocks that
are totally free (especially since most implement the unix "bug" of 
free(ptr);realloc(ptr,...); being valid.)

	Also, mallocing system structures isn't always a good idea, especially
if you're going to pass them to other tasks in the system (if your program
exits, it may free the memory from under the other process - remember,
lwp's with shared memory, not protected tasks communicating through the
kernel.)

>|OK.  Let's keep track of every byte of RAM in the Amiga.  If we allow
>|for 8MB of RAM, then we need an 8Mb map, which comes to a megabyte.
>|If we increase the granularity to,
>|say, a "paragraph" (Intel's term for 16 bytes if memory serves), then
>|8MB is thought of as 512k paragraphs, so the bitmap can fit in 64kB.
>
>Allocating memory in units this small is insane! Name an operating system
>that allocates in units that small! In reality, we use pages of 512 to
>2048 bytes. If we use one BYTE per page, and 1K page size, we need 512 BYTES
>on a half meg box. That ain't bad. Keep track of EVERY byte, suuuuuure.

	AmigaDos.  Many system structures are less than 40 bytes long,
often as small as 14 or even 8.  The system memory allocation granularity
is 8 bytes.  You can't afford to waste many bytes in a 512K system, of
which 350-400K is free at most afer boot - larger granularities would increase
the wastage when allocating all the small system structures.  Remember, no
VM (or MMU unless you have the new A2500 ('020, '881, '851)).  Also, you need
to identify which process controls the memory, so you need one table (1 bit
per cell) pre process, or one global table, with 4 bytes per cell (to store
the process address - we don't have artificial limits on the number of
processes or open files like most Un*x's do.)  You might be able to reduce
that, but it's not a small thing.  Also, it would slow memory allocation,
which is a critical part of a real-time OS, especially on a slow processor
like a 68000.

-- 
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup