[net.micro.amiga] Memory Management w/o MMU"

dan@BBN-PROPHET.ARPA (11/07/85)

From: Dan Franklin <dan@BBN-PROPHET.ARPA>


One minor question regarding memory management still hasn't been answered, and
I'm curious.  Without an MMU, how does the Amiga do multitasking?
Specifically, how does it arrange to permit the same program to run in
different places in memory?  I can see two possibilities:

1. The executable program file contains relocation information.  When the 
program is started up, it is assigned a place in memory and relocated to run at
that address.  This means it could not be "swapped out" and brought in to a
different address if they ever decided to do that, or moved around to open up a
big space for another program, but it is pretty fast.

2. When the program is started up, a designated address register ("base
register") is set to point to the beginning of the program's text and data.
All pointers the program manipulates with are relative to the base register;
given a pointer variable, the compiler always uses the base register as an
index when referring to memory.  Stack accesses could be special-cased; another
register could refer to the "real" current stack frame, and whenever the
address of a stack variable was taken, the base register would be subtracted
from the address before being stored in a pointer variable.  The program can
now be moved around freely, but it's somewhat slower.  There is the problem of
dynamic memory allocation; the pointer the allocator gives back of course can
be made relative to the base register before it's stored in a pointer variable,
but the distance between the base register and the dynamic memory has to be
kept constant as the program is moved around.

And of course they might have done something else I haven't thought of.
Offhand, though, I would guess (1).  Does anyone know?

	Dan

louie%trantor@trantor.UMD.EDU (11/08/85)

From: Louis A. Mamakos <louie@trantor.ARPA>

Executable programs on the amiga consist of a number of "HUNKS".  There
is a hunk directory at the start of the load file that describes the size
of each hunk.  Space is allocated for each hunk, and the hunks are read
into the allocated space.  There is also relocation information that 
describes relocation offsets within that hunk relative to the other hunks.
Note that the hunks do not have to be allocated in one continguous piece
of memory, but rather can be put where ever there is room.  The relocation
at load time take no noticable extra time to perform that I've observed.

Louis A. Mamakos  WA3YMH    Internet: louie@TRANTOR.UMD.EDU
  University of Maryland, Computer Science Center - Systems Programming

bruceb@amiga.UUCP (Bruce Barrett) (11/08/85)

Yes, the "executable" files include relocation information.  This
info is used to relocate code when it is loaded.  Code doed NOT move
around once loaded.  Please note, however, that not all of the code
(and data) need to be contigious.  So small peices of code/data go
into small memory chuncks, larger ones into large chunks.

In Version 1.0 (first customer release) and before the loader would
try to use the "cheapest" memory available, so if you had >512k your
program would get loaded there.  This (extended memory) is not available
to the custom chips so you need(ed) to copy any grahpics / sound info
down into the first 512k.  (After appropriate allocation of memory...)

In Version 1.1 (not yet available) we hope to have the loader
and development environment set up so that you can load segments of
your code in the memory type of your choosing.

--BruceB

ec150fcy@sdcc13.UUCP (Joseph McCaughey{|stu) (11/24/85)

You know, I am getting sick of all these 'how do you do
multi-tasking without an MMU' questions.

GET THIS THRU YOUR HEADS OR TAKE AN OPERATING SYSTEMS CLASS:

THE BARE MINIMUM NEEDED FOR MULTITASKING ARE PROCESSOR
INTERRUPTS OCCURING AT INTERVALS, AND AN INTERRUPT HANDLER.


Larry J. McCaughey

kim@mips.UUCP (Kim DeVaughn) (11/25/85)

> You know, I am getting sick of all these 'how do you do
> multi-tasking without an MMU' questions.
> 
> GET THIS THRU YOUR HEADS OR TAKE AN OPERATING SYSTEMS CLASS:
> 
> THE BARE MINIMUM NEEDED FOR MULTITASKING ARE PROCESSOR
> INTERRUPTS OCCURING AT INTERVALS, AND AN INTERRUPT HANDLER.

Larry -

True.  *IF* the applications you're running are "well-behaved" ... which
is not what one typically finds in a development environment.  

Or, in a production environment, ever try to find that one bug that crashes
the machine and shows up only on odd Thursdays, and then only if you're
running the payroll program and exactly 3 people are running the Foo editor,
and then ... well, you get the idea;  which piece of code do you blame/debug?

At least h/w memory management can *help* you isolate such problems.  No,
MMU's won't eliminate them, but they can at least isolate buggy code to a
certain degree.

/kim
-- 

UUCP:  {decvax,ucbvax,ihnp4}!decwrl!mips!kim
DDD:   415-960-1200
USPS:  MIPS Computer Systems Inc,  1330 Charleston Rd,  Mt View, CA 94043

tim@ISM780B.UUCP (11/26/85)

> GET THIS THRU YOUR HEADS OR TAKE AN OPERATING SYSTEMS CLASS:
>
> THE BARE MINIMUM NEEDED FOR MULTITASKING ARE PROCESSOR
> INTERRUPTS OCCURING AT INTERVALS, AND AN INTERRUPT HANDLER.

But it isn't SAFE to do it without an MMU!  I want to be able to
run a random C program and not have to worry about crashing the
damn machine!

The MMU does not have to be fancy.  A simple MMU that divides the
address space of a process into, say, 256 equal size pages would
be fine.  This is simple to build.

						Tim Smith
						ihnp4!cithep!tim
						ima!is780!tim

dca@edison.UUCP (David C. Albrecht) (11/27/85)

> You know, I am getting sick of all these 'how do you do
> multi-tasking without an MMU' questions.
> 
> GET THIS THRU YOUR HEADS OR TAKE AN OPERATING SYSTEMS CLASS:
> 
> THE BARE MINIMUM NEEDED FOR MULTITASKING ARE PROCESSOR
> INTERRUPTS OCCURING AT INTERVALS, AND AN INTERRUPT HANDLER.
> 
> 
> Larry J. McCaughey

This is true but, it is also like saying all you need to make a fire
is two wooden sticks.  It is unfortunate with all its sophisticated
hardware that the amiga didn't use a system that would provide inter-task
protection and I certainly wouldn't have complained about virtual memory.
Can't say as I blame them, however, virtual memory hasn't made a big
splash in personal computers, the lack of multi-tasking operating
systems in personal computers has not educated very many of their
users in the difficulties of multi-task debugging, and
the 68k series MMU isn't supposed
to be too quick anyway.

David Albrecht

john@anasazi.UUCP (John Moore) (11/29/85)

In article <371@sdcc13.UUCP> ec150fcy@sdcc13.UUCP (Joseph McCaughey{|stu) writes:
>You know, I am getting sick of all these 'how do you do
>multi-tasking without an MMU' questions.
>
>GET THIS THRU YOUR HEADS OR TAKE AN OPERATING SYSTEMS CLASS:
>
>THE BARE MINIMUM NEEDED FOR MULTITASKING ARE PROCESSOR
>INTERRUPTS OCCURING AT INTERVALS, AND AN INTERRUPT HANDLER.
>
>
>Larry J. McCaughey
Woah... not so fast there. The bare minimum needed for multitasking
is a computer. Period. I have written may real-time systems where
the multitasking was performed by simply calling the tasks round
robin style. What you are talking about is the bare minimum for
a TIME-SLICED multitasker.

However, the point about MMU's is not that you can't do multitasking
without one, but that for general multipurpose systems (such as UNIX),
it is bad news to do it without MMU's or some form of memory protection.

The system here is an IBM PC/AT running UNIX in non-protected mode. The
result sometimes is nasty system crashes during applications development
in C. All it takes is one blown pointer and you are in potential trouble.
On the PC, you have much better memory protection on a 68000 (assuming
small or medium model C). A pointer of zero stomps the start of your
data area rather than the start of the Operating System. Since those
pointers are 16 bit, they can only mash the 64K of memory in the
data segment (which may unfortunately also contain other tasks and
code spaces). This offers a little protection. The idea of doing
this in a 68000 makes my skin crawl. However, I'll probably shortly
end up with an Amiga or a 520-St pretty soon, and just have to live
with it - grumpily.

-- 
John Moore (NJ7E/XE1HDO)
{decvax|ihnp4|hao}!noao!terak!anasazi!john
{hao!noao|decvax|ihnp4|seismo}!terak!anasazi!john
terak!anasazi!john@SEISMO.CSS.GOV
(602) 952-8205 (day or evening)
5302 E. Lafayette Blvd, Phoenix, Az, 85018 (home address)

steve@wlbr.UUCP (Steve Childress) (12/03/85)

In article <39700009@ISM780B.UUCP>, tim@ISM780B.UUCP writes:
> 
> > GET THIS THRU YOUR HEADS OR TAKE AN OPERATING SYSTEMS CLASS:
> >
> > THE BARE MINIMUM NEEDED FOR MULTITASKING ARE PROCESSOR
> > INTERRUPTS OCCURING AT INTERVALS, AND AN INTERRUPT HANDLER.
> 
> But it isn't SAFE to do it without an MMU!  I want to be able to
> run a random C program and not have to worry about crashing the
> damn machine!
> 
> The MMU does not have to be fancy.  A simple MMU that divides the
> address space of a process into, say, 256 equal size pages would
> be fine.  This is simple to build.
> 
> 						Tim Smith
> 						ihnp4!cithep!tim
> 						ima!is780!tim

Boy that's for sure good buddy! I can't see how anyone who HAS ACTUALLY
tried serious development on a multitasking computer lacking traps
can argue that this is not essential. This is my experience.

		Regards,
			Steve Childress
			{trwrb, scgvaxd, ihnp4, voder, vortex} !wlbr!steve
		        or	 		        ...wlbr!wlbreng1!steve

guest@ccivax.UUCP (What's in a name ?) (12/05/85)

> > GET THIS THRU YOUR HEADS OR TAKE AN OPERATING SYSTEMS CLASS:
> > 
> > THE BARE MINIMUM NEEDED FOR MULTITASKING ARE PROCESSOR
> > INTERRUPTS OCCURING AT INTERVALS, AND AN INTERRUPT HANDLER.
> > 
> > 
> > Larry J. McCaughey
> 
> This is true but, it is also like saying all you need to make a fire
> is two wooden sticks. 
> It is unfortunate with all its sophisticated
> hardware that the amiga didn't use a system that would provide inter-task
> protection and I certainly wouldn't have complained about virtual memory.
> 
> David Albrecht

It's Ironic that that the Argument used to support putting the OS in ROM
(Both ST and AMIGA) is considered irrelevant when discussing an MMU.
Amiga contains a complicated WCS (Write Control Store) to manage the
kickstart disk, yet assumes that memory protection between applications
is not needed.

AMIGA - Don't put the OS in ROM or WCS, just put an MMU between the 68000
and the rest of the RAM.

MULTI-TASKING WITHOUT AN MMU IS LIKE DRIVING A CAR WITH NO BRAKES.

Opinions are mine, but I'm giving them up for adoption.

rb@ccivax