Path: utzoo!attcan!uunet!lll-winken!ames!oliveb!amiga!jimm
From: jimm@amiga.UUCP (Jim Mackraz)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Unsupported Programming Practices
Message-ID: <3237@amiga.UUCP>
Date: 8 Jan 89 00:56:28 GMT
References: <5605@cbmvax.UUCP> <10227@well.UUCP> <5632@cbmvax.UUCP> <10262@well.UUCP>
Reply-To: jimm@cloyd.UUCP (Jim Mackraz)
Organization: Commodore-Amiga Inc, Los Gatos CA
Lines: 79

In article <10262@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
)In article <5632@cbmvax.UUCP> steveb@cbmvax.UUCP (Steve Beats) writes:
)>In article <10227@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
)>>	I occasionally put RastPorts on my stack; does that count?
)>Yes that certainly does count.
)	AARRGGHHH!  What a bloody nuisance.

I think this is going a little far.  I think we have to divide the problems
up into what will break with what.  Most of the things Carolyn suggested are
things that will cause you problems real soon now, for sure.  There were things
that will break with any non-68000 processor, there were things that will
screw up with the data cache on an 030 or the instruction cache on an 020 or 030,
there were things that will break with new ROM revisions. 

These are all things we'll be seeing soon, if not already.

Now, down the future road, there is this dream of a protected task version
of the Amiga OS.

Let's face it, this isn't going to be a smooth transition.  I do not think that
anyone has compiled a list of the areas where we will find problems with
existing programs when and if we try this.  One thing is sure, tossing things
in MEMF_PUBLIC isn't going to be the only trick.  At least not until a big
list is made of everything that would require this.  Don't forget image planes,
sound samples, the name string of your child task, every gadget, your QBSBlit
entry points, your interrupt structures and data areas, and so on.  There are
probably more obvious ones that have never been listed.

It seems clear to me that moving to protected tasks on an Amiga will be an
evolutionary effort.  No existing program will work, I'd expect, so we'll need
to find a way to support the existing programming model side-by-side with new,
protected tasks.  At that time, there will be new rules and procedures for making
protected tasks.  Things like AddTask() (instead of a system CreateTask()) will
probably have to go, anyway, so there will probably be a whole new paradigm.

If we are to move beyond protection into separate, overlapping logical
address spaces for tasks, this whole "pointers to gadgets hanging off of
windows" and "linked lists of menu items" business has to go, anyway.

I strongly believe that a clear line should be drawn between practices which will
break real soon and those, such as the traditional MEMF_PUBLIC lip service,
which target some very long range, foggy future.

Now, if there are concrete, today type reasons why a rastport can't be on
a stack, perhaps I am missing them.  The key question would be whether anyone
might use the rastport asynchronously (i.e., not as your task), and then,
of course, whether the system tasks will ever be disallowed from using
memory on your stack.

My feeling is that until C-A gives the developers a list of exactly what it
will take to be a protected task, including exactly which functions might
use structures you provide to functions on a schedule other than your own,
it is not a positive step to scare people into tossing everything in the
world into MEMF_PUBLIC.

In the meantime, I put rastport structures on my stack all the time.  I love
doing it, it makes me hot.  Of course, I'm prepared to revise my programs
and issue a timely update to my registered users if:
1) I inadvertantly did something incompatible with a new OS release, or
2) I want to take advantage of major new features in a new OS release, or
3) I think they should all send me $25 more. ;^)

I don't like disagreeing with Steve in public like this, because it clouds
the fact that I take almost every other thing he says as Gospel.

Oh, yes, don't take this posting as a suggestion that the majority of
Carolyn's suggestions are not extremely important.  I'd like a little more
explanation about which of the suggestions are related to protected tasks,
and which are related to anticipated new processors, caches, and MMU usage.

Also, note well that my views do not represent Commodore's official policy.

	jimm

-- 
Jim Mackraz, I and I Computing	   	"Like you said when we crawled down
{cbmvax,well,oliveb}!amiga!jimm          from the trees: We're in transition."
							- Gang of Four
Opinions are my own.  Comments are not to be taken as Commodore official policy.