Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!vecpyr!atari!dyer
From: dyer@atari.UUcp (Landon Dyer)
Newsgroups: net.micro.atari16,net.micro.amiga,net.micro.68k
Subject: Re: 68000 Memory Managment
Message-ID: <412@atari.UUcp>
Date: Wed, 20-Aug-86 01:47:33 EDT
Article-I.D.: atari.412
Posted: Wed Aug 20 01:47:33 1986
Date-Received: Wed, 20-Aug-86 23:21:46 EDT
References: <508@elmgate.UUCP> <767@ark.UUCP>
Organization: Atari Corp., Sunnyvale CA
Lines: 33
Keywords: 68000 atari amiga 68k mmu
Xref: mnetor net.micro.atari16:1649 net.micro.amiga:4331 net.micro.68k:1145

In article <767@ark.UUCP>, gijs@ark.UUCP (Gijs Mos) writes:
> You cannot do virtual memory, you cannot auto-allocate stack space, but you
> *can* do multitasking. 

You can TOO do auto-allocation of stack space with a vanilla 68000, an
MMU, and appropriate compiler support.  Sun did this (I think) in the
Sun-1.  Forgive me if this is pedantic:

Part of each procedure setup (along with the LINK) is a "probe"
instruction (TST.B, say) that tests to see if enough stack is
available to hold the entire local stack frame plus a reasonable
number of arguments.  If there is enough, the TST.B works.  If there
isn't enough stack space, the TST.B will generate a bus error which
signals the OS to increase the stack.  The TST instruction can be
thrown away, since nothing else depends on it.

	_foo:	link	a6,#8		; make room for local args
		tst.b	-208(sp)	; ensure enough stack
		.
		.
		.

Of course this isn't very transparent if you are programming in
assembly language.  But in that case you deserve to suffer.  :->

-- 

-Landon Dyer, Atari Corp.		{sun,lll-lcc,lll-crg!vecpyr}!atari!dyer

/-----------------------------------------------\
| The views represented here do not necessarily | "If Business is War, then
| reflect those of Atari Corp., or even my own. |  I'm a Prisoner of Business!"
\-----------------------------------------------/