THREADS, PROCESSES AND TASKS (YET

84 views
Skip to first unread message

joe....@asb.com

unread,
Jan 19, 1994, 9:08:17 AM1/19/94
to

> I think AmigaDOS is somewhere between MS-DOS and Windows.

Obviously, you are a total idiot and have absolutely no idea what you are
talking about. While OS/2 might be the greatest thing ever on PC's, it's
still sluggish, and no where as efficient as AmigaDOS. Keep dreaming.

//
//
\\/ Amiga....puts all else to shame


Jerry Shekhel

unread,
Jan 19, 1994, 3:13:20 PM1/19/94
to
joe....@asb.com wrote:
: >
: > I think AmigaDOS is somewhere between MS-DOS and Windows.

:
: Obviously, you are a total idiot and have absolutely no idea what you are
: talking about.
:

Obviously, you are an obsessed Amigoid fanatic who doesn't know an operating
system from his excretory system :-P

:
: While OS/2 might be the greatest thing ever on PC's, it's


: still sluggish, and no where as efficient as AmigaDOS.

:

AmigaOS gains its efficiency by sacrificing major OS functionality. This
makes it more suitable for certain niche application, but not for general
purpose stuff.

:
: Keep dreaming.
:

Wow, that's original.
--
+-------------------+----------------------------+---------------------------+
| JERRY J. SHEKHEL | Molecular Simulations Inc. | Cowboy Junkies, Phish, |
| Drummers do it... | Burlington, MA USA | Tribe, Guns N' Roses, |
| ... In rhythm! | je...@msi.com | TAMA, Zildjian, Linux... |
+-------------------+----------------------------+---------------------------+

Jack Radigan

unread,
Jan 19, 1994, 6:29:45 PM1/19/94
to
je...@msi.com (Jerry Shekhel) writes:

>AmigaOS gains its efficiency by sacrificing major OS functionality. This
>makes it more suitable for certain niche application, but not for general
>purpose stuff.

Jerry, that's a crock and you know it.

The lack of a few ancillary OS features does not make it an undesirable
platform for general purpose stuff. There's an awful lot of GNU code running
on the Amiga, is that general purpose enough for you?

Don't confuse the lack of commercial software to be the result of a limited
OS. If that were true than OS/2 would be less capable than Windows based on
native applications available for each.

-jack-

Brian R Turmelle

unread,
Jan 19, 1994, 9:05:39 PM1/19/94
to
In <2hk490$9...@sol.ctr.columbia.edu> je...@msi.com (Jerry Shekhel) writes:

>AmigaOS gains its efficiency by sacrificing major OS functionality. This
>makes it more suitable for certain niche application, but not for general
>purpose stuff.


What kind of bollocks is this? Did MB get another account? :)

Ezra A Story

unread,
Jan 19, 1994, 9:35:53 PM1/19/94
to
In article <2hk490$9...@sol.ctr.columbia.edu> je...@msi.com (Jerry Shekhel) writes:
>joe....@asb.com wrote:
>: >
>: > I think AmigaDOS is somewhere between MS-DOS and Windows.
>: Obviously, you are a total idiot and have absolutely no idea what you are
>: talking about.
>Obviously, you are an obsessed Amigoid fanatic who doesn't know an operating
>system from his excretory system :-P

I quite agree :-). AmigaDOS in terms of the built-in functionality of the
OS is at a lower status than OS/2.. (altho closer to OS/2 than MSDOS :-))

>: While OS/2 might be the greatest thing ever on PC's, it's
>: still sluggish, and no where as efficient as AmigaDOS.
>AmigaOS gains its efficiency by sacrificing major OS functionality. This
>makes it more suitable for certain niche application, but not for general
>purpose stuff.

This I disagree with. Obviously, if that statement held true, nothing
would be written for MacOS or DOS except certain "niche" applications. :-)
Nevermind the fact that the "major" os functionality that you feel is
missing from AmigaDOS hasn't really prevented programs from being written
on it. While ProCalc and Final Writer may not be Excel and Word, they ARE
a spreadsheet and word processor... And reasonably general purpose, don't
you think?

But the statment is certainly a good counter-point to the Amigoid statement
above, as it is just as ridiculous. :-)

--
| Ezra Story | eas...@gold.cs.rit.edu | Ezy (IRC) | ************** |
Your name is being called by sacred things that are not addressed or|
listened to. Sometimes they blow trumpets. | -=_+-=^$%$5-=^$^^^^x |

NICHOLS SCOTT CONRAD

unread,
Jan 20, 1994, 5:03:39 AM1/20/94
to
In article <1994Jan20....@cs.rit.edu> eas...@cs.rit.edu (Ezra A Story) writes:
>In article <2hk490$9...@sol.ctr.columbia.edu> je...@msi.com (Jerry Shekhel) writes:
>>joe....@asb.com wrote:
>>: >
>>: > I think AmigaDOS is somewhere between MS-DOS and Windows.
>
>>: While OS/2 might be the greatest thing ever on PC's, it's
>>: still sluggish, and no where as efficient as AmigaDOS.
>>AmigaOS gains its efficiency by sacrificing major OS functionality. This
>>makes it more suitable for certain niche application, but not for general
>>purpose stuff.
>
>This I disagree with. Obviously, if that statement held true, nothing

O.K., we have that OS/2 is more functional that AmigaOS, but
AmigaOS is more efficient because its a archaic OS as the posts
are implying.

What OS functionality are we talking about? AmigaOS doesn't have
memory protection and other things like that, but it does every
thing an operating system needs to do, load and save files for
instance. Use a word processor, print a post script file,
play a game, down load some files and all at once with no slow
down on an A500? This seems to meet any needs that I would ever
have.

I've used OS/2, Windows, System 7, X, and AmigaOS. I really don't
give a hoot about which operating system is more functional than
the other. My favorite windowing system is X hands down. Then
comes AmigaOS, with System 7, OS/2, and Windows far behind.
Simply put AmigaOS asceticaly pleases me better than any clone or
Mac windowing system.

I personally think OS/2 and Windows are both ugly environments that
don't make me want to use them. They look like something that
one would use at work. The Mac is a good environment for people
that don't like to use CLI's and like to have the computer
do all the thinking. Its great for what it does. I just
don't care for it.
While the Amiga has a more friendly feel
to it, and X is great all around.

Just some opinions.

Scott

Paul van der Heu

unread,
Jan 20, 1994, 2:47:19 AM1/20/94
to
Jerry Shekhel (je...@msi.com) wrote:

: AmigaOS gains its efficiency by sacrificing major OS functionality. This


: makes it more suitable for certain niche application, but not for general
: purpose stuff.

Like what ??

--

Paul 'Starchild' van der Heu, The MotherShip Connection
Anyone seen my sunglasses??
You can't feel cool without your sunglasses !!

Commodore Amiga: 'No Bullshit, Just Excellence!'

Jerry Shekhel

unread,
Jan 20, 1994, 10:50:43 AM1/20/94
to
Jack Radigan (jp...@faatcrl.faa.gov) wrote:
: >
: >AmigaOS gains its efficiency by sacrificing major OS functionality. This

: >makes it more suitable for certain niche application, but not for general
: >purpose stuff.
:
: Jerry, that's a crock and you know it.
:

The hell it is.

:
: The lack of a few ancillary OS features does not make it an undesirable

: platform for general purpose stuff. There's an awful lot of GNU code running
: on the Amiga, is that general purpose enough for you?

:

No. It's a bunch of development tools.

: -jack-

Jerry Shekhel

unread,
Jan 20, 1994, 11:12:11 AM1/20/94
to
Ezra A Story (eas...@cs.rit.edu) wrote:
: >:
: >: While OS/2 might be the greatest thing ever on PC's, it's

: >: still sluggish, and no where as efficient as AmigaDOS.
: >
: >AmigaOS gains its efficiency by sacrificing major OS functionality. This
: >makes it more suitable for certain niche application, but not for general
: >purpose stuff.
:
: This I disagree with. Obviously, if that statement held true, nothing
: would be written for MacOS or DOS except certain "niche" applications. :-)
:

Not at all. Folks, so far everyone who has responded to my comment above
has misunderstood the sentence. Read it again:

... This makes it more suitable for certain niche applications, but not
[more suitable] for general purpose stuff.

See, I'm not saying that AmigaOS is UNsuitable for general purpose stuff,
just no more suitable than the other OS we were talking about, OS/2.

: | Ezra Story | eas...@gold.cs.rit.edu | Ezy (IRC) | ************** |

Ezra A Story

unread,
Jan 20, 1994, 1:40:15 PM1/20/94
to
In article je...@msi.com (Jerry Shekhel) writes:
>
>... This makes it more suitable for certain niche applications, but not
>[more suitable] for general purpose stuff.
>
>See, I'm not saying that AmigaOS is UNsuitable for general purpose stuff,
>just no more suitable than the other OS we were talking about, OS/2.

Ah, point taken. (Now why didn't you say that before? (chuckle) :-))

IMHO, none of the OS's I've seen fit the bill as my perfect OS.. but I doubt
any ever will. Perhaps I'll create my own and let everyone on advocacy flame
each other arguing about its details. :-)

--

| Ezra Story | eas...@gold.cs.rit.edu | Ezy (IRC) | ************** |

Robert Swan

unread,
Jan 20, 1994, 3:39:55 PM1/20/94
to
In article <2hmagr$4...@sol.ctr.columbia.edu> je...@msi.com (Jerry Shekhel) writes:
>Not at all. Folks, so far everyone who has responded to my comment above
>has misunderstood the sentence. Read it again:
>
>... This makes it more suitable for certain niche applications, but not
>[more suitable] for general purpose stuff.
>
>See, I'm not saying that AmigaOS is UNsuitable for general purpose stuff,
>just no more suitable than the other OS we were talking about, OS/2.

Ye Gods Jerry. This one takes the cake!

Two questions:

1) Have you noticed how many times you need to say "Read it again?"
2) Has anyone ever told you that you're a lousy communicator?

If not, consider yourself told.

You get my vote for the specious reasoning in csaa award.

Have fun,

Robert.
--
Robert Swan, | Unborn tomorrow, and dead yesterday,
rob...@g2syd.genasys.com.au | Why fret about them if today be sweet?
Genasys II Pty. Ltd., North Sydney.| Rubaiyat of Omar Khayam.

Jerry Shekhel

unread,
Jan 20, 1994, 4:39:54 PM1/20/94
to
Robert Swan (rob...@g2syd.genasys.com.au) wrote:
: >
: >... This makes it more suitable for certain niche applications, but not

: >[more suitable] for general purpose stuff.
: >
: >See, I'm not saying that AmigaOS is UNsuitable for general purpose stuff,
: >just no more suitable than the other OS we were talking about, OS/2.
:
: Ye Gods Jerry. This one takes the cake!
:
: Two questions:
:
: 1) Have you noticed how many times you need to say "Read it again?"
:

Yes. It's a sign of the times (and the Internet). For many people here,
English is not the first language, and a great many others (like you) simply
neglect to read carefully, even after I reposted the comment and inserted
help text. You see a phrase that raises your blood pressure and respond
without reading the rest.

:
: 2) Has anyone ever told you that you're a lousy communicator?
:

Has anyone ever told you that your debating ability is even worse than
your reading comprehension?

:
: If not, consider yourself told.
:

Ditto.

: Robert.

Robert Swan

unread,
Jan 21, 1994, 2:53:54 AM1/21/94
to
In article <2hmtna$4...@sol.ctr.columbia.edu> je...@msi.com (Jerry Shekhel) writes:
>Robert Swan (rob...@g2syd.genasys.com.au) wrote:
>: >
>: >... This makes it more suitable for certain niche applications, but not
>: >[more suitable] for general purpose stuff.
>: >
>: >See, I'm not saying that AmigaOS is UNsuitable for general purpose stuff,
>: >just no more suitable than the other OS we were talking about, OS/2.
>:
>: Ye Gods Jerry. This one takes the cake!
>:
>: Two questions:
>:
>: 1) Have you noticed how many times you need to say "Read it again?"
>:
>
>Yes. It's a sign of the times (and the Internet). For many people here,
>English is not the first language, and a great many others (like you) simply
>neglect to read carefully, even after I reposted the comment and inserted
>help text. You see a phrase that raises your blood pressure and respond
>without reading the rest.

No Jerry. My blood pressure wasn't even slightly raised. I was simply
observing that you had excelled yourself at your accustomed ducking and
weaving. Your move was a tour de force; totally unexpected. Your
ability to pull unforeseen ambiguity from your own previous statements
is truly amazing.

>: 2) Has anyone ever told you that you're a lousy communicator?
>:
>
>Has anyone ever told you that your debating ability is even worse than
>your reading comprehension?

I have no doubt that my debating skills don't match yours Jerry.
However, I wasn't debating anything here. I was merely recognising
your formidable skills. You're wasted in the computing world.

>+-------------------+----------------------------+---------------------------+
>| JERRY J. SHEKHEL | Molecular Simulations Inc. | Cowboy Junkies, Phish, |
>| Drummers do it... | Burlington, MA USA | Tribe, Guns N' Roses, |
>| ... In rhythm! | je...@msi.com | TAMA, Zildjian, Linux... |
>+-------------------+----------------------------+---------------------------+

Have fun,

ly...@westminster.ac.uk

unread,
Jan 21, 1994, 7:42:34 AM1/21/94
to
In article <2hk490$9...@sol.ctr.columbia.edu> je...@msi.com (Jerry Shekhel) writes:
>joe....@asb.com wrote:
>: >
>: > I think AmigaDOS is somewhere between MS-DOS and Windows.
>:
>: Obviously, you are a total idiot and have absolutely no idea what you are
>: talking about.
>:
>
>Obviously, you are an obsessed Amigoid fanatic who doesn't know an operating
>system from his excretory system :-P

And you do ?????

Jerry Shekhel

unread,
Jan 21, 1994, 11:50:05 AM1/21/94
to
Robert Swan (rob...@g2syd.genasys.com.au) wrote:
: >
: >Yes. It's a sign of the times (and the Internet). For many people here,

: >English is not the first language, and a great many others (like you) simply
: >neglect to read carefully, even after I reposted the comment and inserted
: >help text. You see a phrase that raises your blood pressure and respond
: >without reading the rest.
:
: No Jerry. My blood pressure wasn't even slightly raised. I was simply
: observing that you had excelled yourself at your accustomed ducking and
: weaving. Your move was a tour de force; totally unexpected. Your
: ability to pull unforeseen ambiguity from your own previous statements
: is truly amazing.
:

That's just it. My statement was *not* ambiguous, and it surprises me that
you, presumably a native English speaker, fail to see that.

Here's what really happened. The guy who responded to my statement had
obviously misunderstood it, but since his interpretation made me look like
an Amiga basher, you instantly took his side, never bothering to read the
original statement. That was bad enough, but later, when I tried to clear
up the confusion, you took it as an attempt to "duck and weave". Lovely.

It doesn't matter, anyway. Nothing I say about this hereafter is going to
make any difference. Because I'm seen as some sort of evil invader here,
I'm sure that in most readers' minds this incident has been recorded just
as you say -- an example of my "ducking and weaving". Congratulations.

: Robert Swan, | Unborn tomorrow, and dead yesterday,
--

Jack Radigan

unread,
Jan 21, 1994, 9:01:45 PM1/21/94
to
je...@msi.com (Jerry Shekhel) writes:

>: The lack of a few ancillary OS features does not make it an undesirable
>: platform for general purpose stuff. There's an awful lot of GNU code runnin

>: on the Amiga, is that general purpose enough for you?

>No. It's a bunch of development tools.

Enough with the friggin' moving targets already.

Ok, what "general purpose" applications does the Amiga not have software for?

Now I suppose you're going to say it's not general purpose unless there are
several alternatives for a said category.

-jack-

Jack Radigan

unread,
Jan 21, 1994, 9:09:12 PM1/21/94
to
je...@msi.com (Jerry Shekhel) writes:

>... This makes it more suitable for certain niche applications, but not
>[more suitable] for general purpose stuff.

>See, I'm not saying that AmigaOS is UNsuitable for general purpose stuff,
>just no more suitable than the other OS we were talking about, OS/2.

Taken another way, the phrase "not more suitable" could mean "less suitable".
Depending on how far down the spectrum you're aiming at it could really mean
"unsuitable" as well.

Considering past performance, it's a natural conclusion coming from you.

-jack-

Gregory R Block

unread,
Jan 22, 1994, 1:43:49 AM1/22/94
to
In article <2hk490$9...@sol.ctr.columbia.edu>, Jerry Shekhel (je...@msi.com) wrote:
: AmigaOS gains its efficiency by sacrificing major OS functionality. This

On the other hand, this -ISN'T- true. IF the AmigaOS had VM and MP, it
would still be relatively quick. Enforcer does a great deal of the work
of MP, it just doesn't go the last mile; but in processing terms, it's
almost as intensive.

We can get VM. VM doesn't slow the system down a great deal; it's just
that it does. Mind you, the cost of VM is a shared cost, when MP is
included.

MungWall slows down memory allocations and deallocations to a crawl, as
well, in comparison, and it would be very similar to the impact that RT
would create.

: makes it more suitable for certain niche application, but not for general
: purpose stuff.

Since it's used for general purpose stuff, and many find it suitable,
I'll label this as a rather un-humble opinion, and leave it behind.

: Wow, that's original.

No, it's Wurthers. Don't you wish you could look younger too?

Greg

--
(: (: (: (: Have you overdosed on smileys today? Why NOT!?! :) :) :) :)
(: "He uses statistics like a drunkard uses a light-post; :)
(: for support, not for illumination." -Anonymous :)
(: (: (: (: (: (: (: (: (: (: (: (: :) :) :) :) :) :) :) :) :) Wubba :)

Gregory R Block

unread,
Jan 22, 1994, 1:48:26 AM1/22/94
to
In article <2hk490$9...@sol.ctr.columbia.edu>, Jerry Shekhel (je...@msi.com) wrote:
: AmigaOS gains its efficiency by sacrificing major OS functionality. This

Oh, I forgot.

This from a person without a clue as to how the AmigaOS works; little
hands-on experience, very skimpy knowledge, and has never cracked open a
book on the internals in his life.

This takes the cake as some of your most clueless drivel. Why? Because
you can't even begin to tell me what OS functionality AmigaOS -DOES-
have. You simply don't have enough information to make that claim, so it
deserves, with the rest of your post, to be thrown into the bit bucket.

You're usually more careful than that. If you're going to have an
opinion, you MAY as well form it from real knowledge, instead of the
vapor that hangs off of your words like so much LA smog.

Kyonghun Lee

unread,
Jan 22, 1994, 3:09:50 AM1/22/94
to
In article <2hqi7q...@uwm.edu> gbl...@csd4.csd.uwm.edu (Gregory R Block) writes:
>hands-on experience, very skimpy knowledge, and has never cracked open a
>book on the internals in his life.
>
>This takes the cake as some of your most clueless drivel. Why? Because
>you can't even begin to tell me what OS functionality AmigaOS -DOES-
>have. You simply don't have enough information to make that claim, so it
>deserves, with the rest of your post, to be thrown into the bit bucket.
>
Ok. I could not help but butting in on this.
I got two things:

Judging fromy your last 15+ postings, I think you ENJOY bashing
other people WITHOUT getting the entire context of the origial
posters claim. Your recent response to my "Mac vs...."
posting clearly proves this,

Also( I really hate to do this kind of generalizatin but...) most
of your postings seem to restate what has already beebn said in the
other follow-ups for the origianl posting, which, incidentally,
makes YOUR posting rather....redundant?

Now back to the topic at hand:

You said that you can't start counting the features of AmigaOSes.

Thus, making the counter claim that the AmigaOS is a minimalist
approcah is wrong.

Well, the "countless" features you mentined are usually
taken granted in other modern Oses. It is not like there are
featuers that are present in AmigaOS and are not anywhere else.

It is a FACT that Amiga lacks the featueres of modern day
big-time Oses like the OS/2, NT, various UNIX, or even System 7
(network wise).

I don't think that you have a CLUE about what Amiga is lacking
as an OS as opposed to the original posters claim that
Amiga is a minimalist-OS.

Examples? OLE 2.0. NetDDE. Enough said.

Kyonghun
:
>>Kyonghun Lee (kyon...@cae.wisc.edu -or- kyon...@smartcad2.wisc.edu)<<<<<<<
___ ___
| \ / | Class of '93 | | | | | | Class of 19??
| \ / | University of \ \ / \ / / University of
| |\ \/ /| | Michigan \ \ / /\ \ / / Wisconsin-Madison
| | \ / | | Mechanical Engin. \ \/ / \ \/ / Mechanical Engineering
| | \/ | | Go Blue! | | | | Go Badgers? ...NOT!
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
"...I know engineers, they love to change things..." Dr. McCoy, USS Enterprise
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Paul van der Heu

unread,
Jan 21, 1994, 3:13:34 AM1/21/94
to
Jerry Shekhel (je...@msi.com) wrote:

: : >... This makes it more suitable for certain niche applications, but not
: : >[more suitable] for general purpose stuff.

: Yes. It's a sign of the times (and the Internet). For many people here,


: English is not the first language, and a great many others (like you) simply
: neglect to read carefully, even after I reposted the comment and inserted
: help text. You see a phrase that raises your blood pressure and respond
: without reading the rest.

This is nonsense and as far as I'm concerned you obviously hate to loose an
argument and as soon as you are about to, you either change the subject slightly
or change your own words.

My understanding of English is quite good and :

This makes it more suitable for certain niche applications, but not

for general purpose stuff.

means you are saying the subject is not suitable for anything but specialized
apps. while:

This makes it more suitable for certain niche applications, but not
[more suitable] for general purpose stuff.

means you are saying the subject is not more suitable for anything but
specialized apps. compared to another competitive subject.

These two paragraphs are quite different and thus you (again) change your
story in order to win the argument or, better put, at least not to lose it.

: : 2) Has anyone ever told you that you're a lousy communicator?

: Has anyone ever told you that your debating ability is even worse than
: your reading comprehension?

And you are obviously a bad loser

John Engelhart

unread,
Jan 23, 1994, 3:06:02 PM1/23/94
to
In article <2hqhv5...@uwm.edu> gbl...@csd4.csd.uwm.edu (Gregory R Block) writes:
>In article <2hk490$9...@sol.ctr.columbia.edu>, Jerry Shekhel (je...@msi.com) wrote:
>: AmigaOS gains its efficiency by sacrificing major OS functionality. This
>
>On the other hand, this -ISN'T- true. IF the AmigaOS had VM and MP, it
>would still be relatively quick. Enforcer does a great deal of the work
>of MP, it just doesn't go the last mile; but in processing terms, it's
>almost as intensive.

I have to disagree. VM is realitvly easy to add without incuring
much of an overhead. The ATC on the MMU on the '40 can 'cache' up to
256K or 512K of memory references. That sounds a bit confusing, so
here's how it works. The ATC (address translation cache) has 64
entrys. Each entry governs (on a '40) either a 4K page or 8K page.
So, 64 entry's * 4K or 8K is 256K and 512K, respectivly. Anything
that isn't cached in the ATC causes a miss and it miss find the page
descriptor. Not that bad, but it does cause a slow down. So,
technically, switching on the MMU can cause a slowdown.

Now, about the MP remark. Adding MP would significantly degrade
performace. Have you ever done any programming on the amiga? If so
you'll know how much it relies on message passing. The reason it's so
quick right now is because when Task A passes a message to Task B,
only a pointer to the memory is exchanged. Under a MP system, Task B
can't directly read Task A's data, so the OS has to copy the data into
a temporary area so Task B can legally read it. BIG performance hit.

I've heard "lore" that the original Amiga designs included both MP
and the hardware to enforce it. At the time, the hardware neccesary
to do it on a 68000 (this is '83/'84/'85 when this is being developed,
remember) slowed the system down. It was an external part (the 68851)
and the 68K first had to go through that to get to the memory. I
could imagine a slight to medium performace hit from this alone. Add
the problems already discussed about the message passing situation,
and you've got some serious performance problems. So the lore goes
that this is why it was removed.

Oh, BTW, enforcer does no such Memory Protection. It only aids in
finding hits to $00000000 and non-existant memory. It does a few
other things but I can't remember off hand. It provides NO protection
(well, I suppose you could count $0 as protected.. :).

>
>We can get VM. VM doesn't slow the system down a great deal; it's just
>that it does. Mind you, the cost of VM is a shared cost, when MP is
>included.

I think, off hand, VM is tied to A) How much memory your system has,
B) How much memory is currently being 'requested', C) How fast your
secondary storage is able to satisfy page requests, D) How active your
system is (in terms of memory paging demands). Please note this isn't
intended to be an all encompasing list, but any one of these factors
can change how much of an impact VM has on your system.

>
>MungWall slows down memory allocations and deallocations to a crawl, as
>well, in comparison, and it would be very similar to the impact that RT
>would create.

Hmm, maybe it's just my '40, but only the most intensive mungwall
options slow my system down. I think it's the "check every reference"
option. Other than that the performance hit is negligable.
________
-Hermes---------------------------------------------------|____ /------
| jo...@uhunix.uhcc.hawaii.edu / / (tm)|
| -CEO, Digitally Inaccurate Systems Inc. (A wholly owned / / |
| subsidiary of Zang(tm) Industries Incorporated). / /\ |\ |/~ |
| -Vice President in charge of Information Systems, Zang. / /--\| \|\/~|
----------------------------------------------------------/________|-----
| Zang(tm): "Racist, sexist, homophobic and we probably own you." |
-------------------------------------------------------------------------

John Engelhart

unread,
Jan 23, 1994, 3:19:22 PM1/23/94
to
In article <2hqi7q...@uwm.edu> gbl...@csd4.csd.uwm.edu (Gregory R Block) writes:
>In article <2hk490$9...@sol.ctr.columbia.edu>, Jerry Shekhel (je...@msi.com) wrote:
>: AmigaOS gains its efficiency by sacrificing major OS functionality. This
>
>This from a person without a clue as to how the AmigaOS works; little
>hands-on experience, very skimpy knowledge, and has never cracked open a
>book on the internals in his life.
>

Now wait a second. I happen to agree with him. I may disagree with
the choice of 'major', I might opt to use 'some'.

Here's what I mean by giving up some OS functionality:

No resource tracking.
No memory protection.

Now, if someone who's had experience with other OS's and is
knowedgable about computers read that, they could very easily (and
legitimatly) make the claim "AmigaOS gains its efficiency by
sacrificing major OS functionality". It gains ALOT of efficiency by
giving up the two mentioned OS features.

What do you lose by giving these two things up? IMHO, alot, but
you're still left with a very useable system. How many times have you
had an unrecoverable system crash? Those two features would end AT
LEAST 90% of those and allow you to recover the resources used by the
errant program and continue using your computer. A major boon to
software developers as this ends the program->crash->REBOOT->debug.
Rebooting takes some time, at least for me.

These features are considered standard on most modern OS's. So now
if you don't have them, you're missing something major from the OS.
He has a compleatly legitimat and probably informed opinion even if he
never cracked open an RKM.

Ezra A Story

unread,
Jan 23, 1994, 5:28:32 PM1/23/94
to
In article jo...@uhunix.uhcc.Hawaii.Edu (John Engelhart) writes:

>In article gbl...@csd4.csd.uwm.edu (Gregory R Block) writes:
>>
>>On the other hand, this -ISN'T- true. IF the AmigaOS had VM and MP, it
>>would still be relatively quick. Enforcer does a great deal of the work
>>of MP, it just doesn't go the last mile; but in processing terms, it's
>>almost as intensive.
>
>technically, switching on the MMU can cause a slowdown.

But *relatively*, I don't think it would add tremendous overhead. Remember
that having MP does not necessarily mean having a completely new virtual
mem organization for each process. All you need to do is overlay the MMU
on the current memory map and mark pages invalid, etc.. like enforcer does.
Although my knowledge of the 680x0 MMU's is limited so perhaps there are
issues I don't know about. :-)

> Now, about the MP remark. Adding MP would significantly degrade
>performace. Have you ever done any programming on the amiga? If so
>you'll know how much it relies on message passing. The reason it's so
>quick right now is because when Task A passes a message to Task B,
>only a pointer to the memory is exchanged. Under a MP system, Task B
>can't directly read Task A's data, so the OS has to copy the data into
>a temporary area so Task B can legally read it. BIG performance hit.

No it doesn't, all it does is pass the pointer because the memory area was
marked publically readable by the application (ie. the whole point of the
now-useless MEMF_PUBLIC flag). Note that the OS couldn't do this for you
on a PutMsg() because in many cases (like Devices) you also pass pointers
to other memory areas in the message itself.. which it couldn't keep track
of (well, it could, but we're assuming that AmigaDOS doesn't change in any
drastic way other than MP)...

> I've heard "lore" that the original Amiga designs included both MP
>and the hardware to enforce it. At the time, the hardware neccesary
>to do it on a 68000 (this is '83/'84/'85 when this is being developed,
>remember) slowed the system down. It was an external part (the 68851)
>and the 68K first had to go through that to get to the memory. I
>could imagine a slight to medium performace hit from this alone. Add
>the problems already discussed about the message passing situation,
>and you've got some serious performance problems. So the lore goes
>that this is why it was removed.

I bet the cost was a factor as well.

> Oh, BTW, enforcer does no such Memory Protection. It only aids in
>finding hits to $00000000 and non-existant memory. It does a few
>other things but I can't remember off hand. It provides NO protection
>(well, I suppose you could count $0 as protected.. :).

It marks certain pages of memory invalid, which is basically all you need
to implement MP on a basic level in AmigaDOS (discounting software
issues).

Ralph Schmidt

unread,
Jan 24, 1994, 3:00:47 AM1/24/94
to
eas...@cs.rit.edu (Ezra A Story) writes:

>But *relatively*, I don't think it would add tremendous overhead. Remember
>that having MP does not necessarily mean having a completely new virtual
>mem organization for each process. All you need to do is overlay the MMU
>on the current memory map and mark pages invalid, etc.. like enforcer does.
>Although my knowledge of the 680x0 MMU's is limited so perhaps there are
>issues I don't know about. :-)

You forgot 2 important points:

o 68040 has 4k/8K pages..so you must align everything that must be
protected to 4k borders. If you accept missaligned areas you
have to check *everytime* in a big list if that access was legal.
=>slowdown

o Well..ok..let's assume we have MP. Who gives us resource tracking ?


it's not that easy:-B

Regards
--
Ralph Schmidt la...@uni-paderborn.de
University of Paderborn (Germany)

Alex Topic

unread,
Jan 24, 1994, 7:26:45 AM1/24/94
to
> Now, about the MP remark. Adding MP would significantly degrade
> performace. Have you ever done any programming on the amiga? If so
> you'll know how much it relies on message passing. The reason it's so
> quick right now is because when Task A passes a message to Task B,
> only a pointer to the memory is exchanged. Under a MP system, Task B
> can't directly read Task A's data, so the OS has to copy the data into
> a temporary area so Task B can legally read it. BIG performance hit.

Okay I find all this interesting and have an idea? Though I'm not sure if
it will work.. if it doesn't email me.. anyhow..

I don't know too much about MMU's, don't even own one. However I
have a rough idea in how they work. Anyhow couldn't you do this.. Have a
MMU node list? And maybe have a function called AllocMessage()... allocates
your message in a part of memory.. MMU manager just adds it to it node
list... So when ever a message is sent to another task... it can just
GetMsg()... though it has to look at the MMU manager message node list...
see if its a shared message or something.. if so.. then just get the
pointer to it and MMU manager doesn't protect the message... SOrt of have
SEMI-MEMORY protection. This would cut down the chances of crashing
wouldn't it? Now it wouldn't be 100% memory protection, but wouldn't put
the odds down if there wasn't any protection at all? Would this work? Can
some one come up with a better solution... if so post a message under a new
thread "MEMORY PROTECTION..etc"

thanks for listening..

ps: Please don't flame or laugh at my idea.. just trying to figure
something out..ttul

-- Via DLG Pro v1.0

-Alex Topic.

Ezra A Story

unread,
Jan 24, 1994, 10:13:05 AM1/24/94
to
In article <2hvv7f$9...@haegar2.uni-paderborn.de> la...@haegar2.uni-paderborn.de (Ralph Schmidt) writes:
>
>You forgot 2 important points:
>
> o 68040 has 4k/8K pages..so you must align everything that must be
> protected to 4k borders. If you accept missaligned areas you
> have to check *everytime* in a big list if that access was legal.
> =>slowdown

Well that could be solved by allocating in pages and using a memory pool
system similar to what V39+ has now. So I guess I'm going for the former
solution. :-)

> o Well..ok..let's assume we have MP. Who gives us resource tracking ?
>
>it's not that easy:-B

Well, thats the tough part. Noone said it would be easy. We're just
speculating on the performance impact it would have. :-)

RT is even worse than MP in terms of implementation, since AMigaDOS allows
you to allocate some memory, attach it to a public list, and then go away
(leaving the memory behind). It might also drag in performance as well,
but I couldn't tell you that for sure until it was actually implemented..
which will probably never happen. :-)

I suppose one could modify AmigaDOS enough to pull it off, but it is
certainly a good argument again the folklore that RT was included in the
early version of ADOS (maybe in CAOS?).

Sigh, it woul be nice not to have to worry about backwards compatibilty
wouldn't it? :-)

Jerry Shekhel

unread,
Jan 24, 1994, 11:18:51 AM1/24/94
to
Jack Radigan (jp...@faatcrl.faa.gov) wrote:
: >
: >See, I'm not saying that AmigaOS is UNsuitable for general purpose stuff,

: >just no more suitable than the other OS we were talking about, OS/2.
:
: Taken another way, the phrase "not more suitable" could mean "less suitable".
: Depending on how far down the spectrum you're aiming at it could really mean
: "unsuitable" as well.
:

Jack, we can discuss nothing if we don't speak the same language. Since
when does "not more" mean "less"?

: -jack-

Jack Radigan

unread,
Jan 24, 1994, 5:24:21 PM1/24/94
to
je...@msi.com (Jerry Shekhel) writes:

>: Taken another way, the phrase "not more suitable" could mean "less suitable"

>: Depending on how far down the spectrum you're aiming at it could really mean
>: "unsuitable" as well.

>Jack, we can discuss nothing if we don't speak the same language. Since
>when does "not more" mean "less"?

Since when? Like, since always. Jeez, just look up "less" in the dictionary
to see that it means "not more".

-jack-

John Engelhart

unread,
Jan 24, 1994, 4:52:39 PM1/24/94
to
Sorry if this appears twice.. One the the machines over here hicuped.

In article <1994Jan23.2...@cs.rit.edu> eas...@cs.rit.edu (Ezra A Story) writes:
>In article jo...@uhunix.uhcc.Hawaii.Edu (John Engelhart) writes:
>>In article gbl...@csd4.csd.uwm.edu (Gregory R Block) writes:
>>>
>>>On the other hand, this -ISN'T- true. IF the AmigaOS had VM and MP, it
>>>would still be relatively quick. Enforcer does a great deal of the work
>>>of MP, it just doesn't go the last mile; but in processing terms, it's
>>>almost as intensive.
>>
>>technically, switching on the MMU can cause a slowdown.
>
>But *relatively*, I don't think it would add tremendous overhead. Remember
>that having MP does not necessarily mean having a completely new virtual
>mem organization for each process. All you need to do is overlay the MMU

Whoa, hold on here. It appears to me that you've mixed VM and MP as
though they were synonomous. This IS NOT the case. It is
considerably easier to add VM to the current amiga line (if the
systems have an MMU, naturally. But look at the latest systems. They
do not.). However, MP is so radically different from VM I don't see
how you could confuse the two unless I've read your statement
incorrectly.

>on the current memory map and mark pages invalid, etc.. like enforcer does.
>Although my knowledge of the 680x0 MMU's is limited so perhaps there are
>issues I don't know about. :-)

While my MMU knowledge is quite low as well this fits entirely into
what I know about it. However, these is a basic fundamental problem
with adding MP as you suggest. What do you mark as invalid? There's
NO WAY to tell. Remember, AmigaDOS provides no resource tracking. It
doesn't know who owns what, so how can it say "Task A can't write in
this location". How does Exec know that Task A can't write to that
location? Answer? It can't.

>
>> Now, about the MP remark. Adding MP would significantly degrade
>>performace. Have you ever done any programming on the amiga? If so
>>you'll know how much it relies on message passing. The reason it's so
>>quick right now is because when Task A passes a message to Task B,
>>only a pointer to the memory is exchanged. Under a MP system, Task B
>>can't directly read Task A's data, so the OS has to copy the data into
>>a temporary area so Task B can legally read it. BIG performance hit.
>
>No it doesn't, all it does is pass the pointer because the memory area was
>marked publically readable by the application (ie. the whole point of the
>now-useless MEMF_PUBLIC flag). Note that the OS couldn't do this for you
>on a PutMsg() because in many cases (like Devices) you also pass pointers
>to other memory areas in the message itself.. which it couldn't keep track
>of (well, it could, but we're assuming that AmigaDOS doesn't change in any
>drastic way other than MP)...
>

Yes.. The now useless MEMF_PUBLIC flag. This flag was so horribly
abused that it can not possibly be used to hint at providing memory
protection. I belive that you yourself invalidate your first
sentance.

Trying to run on an MP protected amiga system that actually used
MEMF_PUBLIC to tell what to leave globably readable would be an
excercise in futality. Hardly anything would run.

Here's another take on it: Let's suppose we're going to do the
following. We're going to add limited support of MP. Any call to
LoadSeg() causes the hunks it loads to be protected from all other
tasks. The task just loaded is the only task able to read/write
inside those hunks. All AllocMems() that the task does are considered
global (because MEMF_PUBLIC was misused). Ok.. That's a pretty decent
system but still alot of programs will crash or have alot of problems.
Sometimes, because we (the programmers) never had to deal with the
consiquences of an MP system, we sometimes put MEMF_PUBLIC data in our
code. Example:

Watch_Me_Crash()
{
char Cant_Read_Me_Buffer[4096];

Msg.Data->(APTR)Cant_Read_Me_Buffer;
PutMsg();
}

You get the idea.. Fails. Why? Is Cant_Read_Me_Buffer public?
Nope, it's on the stack which is task private. Or, it could be
uninitialized BSS global data which LoadSeg() would mark as PRIVATE
because there was no way to tell that it was meant to be passed in a
MEMF_PUBLIC mannor.

The above example works now because no memory protection is
enforced. These coding practices got away because of that. If we had
MP from the start we'd quickly learn to recognize that this task
crashed because it's dealign with task private information.
Unfortunatly, SO MUCH SOFTWARE has been written WITHOUT this
mentality. To make this friendly, we'd have to make CRMB[4096] an
AllocMem with the public attribute. Now tell me honestly, how many
people have done that? I know I haven't.

>> Oh, BTW, enforcer does no such Memory Protection. It only aids in
>>finding hits to $00000000 and non-existant memory. It does a few
>>other things but I can't remember off hand. It provides NO protection
>>(well, I suppose you could count $0 as protected.. :).
>
>It marks certain pages of memory invalid, which is basically all you need
>to implement MP on a basic level in AmigaDOS (discounting software
>issues).

Again, marking pages invalid is only the beginning. Yes, the
hardware support is there. But ADOS has no way of knowing which pages
to mark as invalid. Thus, we have the crux of the problem.

BTW, with enforcer running, try and trash someone elses program..
Yep, it's possible. :)


________
-Hermes---------------------------------------------------|____ /------
| jo...@uhunix.uhcc.hawaii.edu / / (tm)|
| -CEO, Digitally Inaccurate Systems Inc. (A wholly owned / / |
| subsidiary of Zang(tm) Industries Incorporated). / /\ |\ |/~ |
| -Vice President in charge of Information Systems, Zang. / /--\| \|\/~|
----------------------------------------------------------/________|-----

| Zang(tm): "Peace, While it's lucrative." |
-------------------------------------------------------------------------

Kenneth Jamieson

unread,
Jan 24, 1994, 6:49:02 PM1/24/94
to
In article <1994Jan24.1...@cs.rit.edu>,

Ezra A Story <eas...@cs.rit.edu> wrote:
>
>I suppose one could modify AmigaDOS enough to pull it off, but it is
>certainly a good argument again the folklore that RT was included in the
>early version of ADOS (maybe in CAOS?).
>
>Sigh, it woul be nice not to have to worry about backwards compatibilty
>wouldn't it? :-)

hehehe - considering all the heat PC types get about worrying about it
I would think the most .advocacy type would be happy to toss all the software
to move ahead :-):-):-)

>
>--
>| Ezra Story | eas...@gold.cs.rit.edu | Ezy (IRC) | ************** |
>Your name is being called by sacred things that are not addressed or|
>listened to. Sometimes they blow trumpets. | -=_+-=^$%$5-=^$^^^^x |


--
Too tired to think of a funny .signature.
Kenneth Jamieson
tr...@shasti.xei.com / tr...@xei.jvnc.net / tr...@wisdom.bubble.org
Via Linux ALPHA 0.99 PL14l - Thanks Linus!

Ezra A Story

unread,
Jan 25, 1994, 12:18:32 AM1/25/94
to
In article jp...@faatcrl.faa.gov (Jack Radigan) writes:

>je...@msi.com (Jerry Shekhel) writes:
>
>>Jack, we can discuss nothing if we don't speak the same language. Since
>>when does "not more" mean "less"?
>
> Since when? Like, since always. Jeez, just look up "less" in the dictionary
>to see that it means "not more".

ENOUGH! THis has got to be the most ridiculous thread, even for advocacy.
Jerry is being ambiguous, and Jack is suffering from the classic case of
"If its not one its the other". (although neither seems to realize it)

"Not More" means whatever is not "More" :-). What is NOT more? *Less OR
the same*, fucking dolts. :-)

Ezra A Story

unread,
Jan 25, 1994, 12:41:41 AM1/25/94
to
In article jo...@uhunix.uhcc.Hawaii.Edu (John Engelhart) writes:
>In article eas...@cs.rit.edu (Ezra A Story) writes:
>>In article jo...@uhunix.uhcc.Hawaii.Edu (John Engelhart) writes:
>>>In article gbl...@csd4.csd.uwm.edu (Gregory R Block) writes:
>
> Whoa, hold on here. It appears to me that you've mixed VM and MP as
>though they were synonomous. This IS NOT the case. It is
>considerably easier to add VM to the current amiga line (if the
>systems have an MMU, naturally. But look at the latest systems. They
>do not.). However, MP is so radically different from VM I don't see
>how you could confuse the two unless I've read your statement
>incorrectly.

Actually in the context of the discussion, I was considering them the same
in terms of overhead. The discussion was about performance impact, not
how to add MP to AmigaDOS. In the case of adding it to AmigaDOS, while it
wouldn't be impossible, it would be damn close.. :-) (That is, if we
consider backwards compatibility)

> While my MMU knowledge is quite low as well this fits entirely into
>what I know about it. However, these is a basic fundamental problem
>with adding MP as you suggest. What do you mark as invalid? There's
>NO WAY to tell. Remember, AmigaDOS provides no resource tracking. It
>doesn't know who owns what, so how can it say "Task A can't write in
>this location". How does Exec know that Task A can't write to that
>location? Answer? It can't.

In short, MEMF_PUBLIC (or a flag with the same intended effect).

>>No it doesn't, all it does is pass the pointer because the memory area was
>>marked publically readable by the application (ie. the whole point of the
>>now-useless MEMF_PUBLIC flag). Note that the OS couldn't do this for you
>>on a PutMsg() because in many cases (like Devices) you also pass pointers
>>to other memory areas in the message itself.. which it couldn't keep track
>>of (well, it could, but we're assuming that AmigaDOS doesn't change in any
>>drastic way other than MP)...
>
> Yes.. The now useless MEMF_PUBLIC flag. This flag was so horribly
>abused that it can not possibly be used to hint at providing memory
>protection. I belive that you yourself invalidate your first
>sentance.

No I don't, the discussion was about performance impact IF AmigaDOS HAD
MP, not adding MP to AmigaDOS now. Obviously, from what I said above,
I don't believe it's THAT easy. :-)

> The above example works now because no memory protection is
>enforced. These coding practices got away because of that. If we had
>MP from the start we'd quickly learn to recognize that this task
>crashed because it's dealign with task private information.

Thats the angle I was coming from. I was talking about the performance
impact of MP would have assuming AmigaDOS had it from the beginning. We
must have gotten our wires crossed somewhere. I basically totally agree
with your points about adding MP with backwards compatibility to AmigaDOS
NOW.

Graeme Fenwick

unread,
Jan 25, 1994, 10:32:04 AM1/25/94
to
Jack Radigan (jp...@faatcrl.faa.gov) wrote:

: Since when? Like, since always. Jeez, just look up "less" in the dictionary


: to see that it means "not more".

Well, 10 is "not more" than 10, but it's not "less" than 10 either.
Not more means less OR equal to, ie <=

and not less on its own ie <.

I don't know what dictionary you are using, but it sounds like the bloke
who wrote it picked the wrong sort of mushrooms for his tea...

-------------------------------------------------------------------------------
"Time flies like an arrow, but fruit flies like a banana" - Anon (and Ariston)
-------------------------------------------------------------------------------
Graeme Fenwick gfen...@uk.ac.dund.mcs
-------------------------------------------------------------------------------

John Engelhart

unread,
Jan 25, 1994, 3:21:40 AM1/25/94
to
In article <Alex_To...@amsbbs.bc.ca> Alex_...@amsbbs.bc.ca (Alex Topic) writes:
> Okay I find all this interesting and have an idea? Though I'm not sure if
>it will work.. if it doesn't email me.. anyhow..
>
> I don't know too much about MMU's, don't even own one. However I
>have a rough idea in how they work. Anyhow couldn't you do this.. Have a
>MMU node list? And maybe have a function called AllocMessage()... allocates
>your message in a part of memory.. MMU manager just adds it to it node
>list... So when ever a message is sent to another task... it can just
>GetMsg()... though it has to look at the MMU manager message node list...
>see if its a shared message or something.. if so.. then just get the
>pointer to it and MMU manager doesn't protect the message... SOrt of have
>SEMI-MEMORY protection. This would cut down the chances of crashing
>wouldn't it? Now it wouldn't be 100% memory protection, but wouldn't put
>the odds down if there wasn't any protection at all? Would this work? Can
>some one come up with a better solution... if so post a message under a new
>thread "MEMORY PROTECTION..etc"
>

Hmmm. While your system may work it does require a new set of OS
routines to make it happen. Thus, it would not extend it's protection
to the already existing software base. I'm not saying your idea is
bad or anything. The core of the idea (adding a set of routines to
provide MP for tasks that want to take advantage of it and not
providing MP to older software) may be compleatly workable.

Imagine a "resource.library" where it has a set of functions to
control who has access to which resources. Any program that was
resource.library aware could register it's resources with it and the
resource.library would extend protection to those areas. It would
mean that any program writte to take advantage of it would be pretty
crash proof. BUT, all the old programs (3.1 and below, let's say)
could still take down the system. An interesting idea, but it still
feels like a kludge to me. Kind of like making MS-DOS systems
multitask. ;)


________
-Hermes---------------------------------------------------|____ /------
| jo...@uhunix.uhcc.hawaii.edu / / (tm)|
| -CEO, Digitally Inaccurate Systems Inc. (A wholly owned / / |
| subsidiary of Zang(tm) Industries Incorporated). / /\ |\ |/~ |
| -Vice President in charge of Information Systems, Zang. / /--\| \|\/~|
----------------------------------------------------------/________|-----

| Zang(tm): "Visualize Global Domination" |
-------------------------------------------------------------------------

Jerry Shekhel

unread,
Jan 25, 1994, 11:05:32 AM1/25/94
to
Jack Radigan (jp...@faatcrl.faa.gov) wrote:
: >
: >Jack, we can discuss nothing if we don't speak the same language. Since

: >when does "not more" mean "less"?
:
: Since when? Like, since always. Jeez, just look up "less" in the
: dictionary to see that it means "not more".
:

Sorry, Jack. "Not more" means "equal or less", not "less". Think about it.
I can't believe I have to explain this to someone who uses computers and
claims to do some programming.

Bohuslav Rychlik

unread,
Jan 25, 1994, 5:05:22 PM1/25/94
to
Excerpts from netnews.comp.sys.amiga.advocacy: 25-Jan-94 Adding Memory
Protection (M.. by John Enge...@uhunix.uh
> Imagine a "resource.library" where it has a set of functions to
> control who has access to which resources. Any program that was
> resource.library aware could register it's resources with it and the
> resource.library would extend protection to those areas. It would
> mean that any program writte to take advantage of it would be pretty
> crash proof. BUT, all the old programs (3.1 and below, let's say)
> could still take down the system. An interesting idea, but it still
> feels like a kludge to me. Kind of like making MS-DOS systems
> multitask. ;)

If that'd be the only way to do it, it'd still be better than nothing!

So who here is convinced that adding memory protection to the OS now
(without using the afore-mentioned method) would break
backwards-compatibility to 2.04 programs? I don't know; it just still
seems to me that it ought to be possible.


-------------------------------------------------------------
Bohuslav Rychlik (Bob), ryc...@cmu.edu, br...@andrew.cmu.edu
-------------------------------------------------------------

Gregory R Block

unread,
Jan 25, 1994, 7:16:56 PM1/25/94
to
In article <1994Jan23.2...@cs.rit.edu>, Ezra A Story (eas...@cs.rit.edu) wrote:
: But *relatively*, I don't think it would add tremendous overhead. Remember

: that having MP does not necessarily mean having a completely new virtual
: mem organization for each process. All you need to do is overlay the MMU
: on the current memory map and mark pages invalid, etc.. like enforcer does.
: Although my knowledge of the 680x0 MMU's is limited so perhaps there are
: issues I don't know about. :-)

You're exactly right: Which is why I compared Enforcer directly to an MP
system. The question: IS THERE a noticeable slowdown? The answer?
Yes. IS IT WORTH IT.

Tougher question. Enforcer doesn't do much right now: It's a static MMU
table, essentially. The moment you begin to change MMU tables based on
what task is running in order to act as MP, things become closer to
impossible.

How do I know? Well, I'm sure people have heard of Guardian Angel by
now; a rumored C= development tool that would memory-protect unallocated
memory. When I heard it would never be released, I began asking how it
could be done, and began writing Guardian.

Guardian is in stasis; as a development tool, it's fascinating. It's not
functional yet, but even in its current state, performance is
jaw-droppingly slower. Slower than MungWall and Enforcer put together.

No, this isn't acceptable. And it's not even _DONE_ yet. And it's STILL
not doing the job--it's only protecting unallocated memory.

: now-useless MEMF_PUBLIC flag). Note that the OS couldn't do this for you


: on a PutMsg() because in many cases (like Devices) you also pass pointers
: to other memory areas in the message itself.. which it couldn't keep track
: of (well, it could, but we're assuming that AmigaDOS doesn't change in any
: drastic way other than MP)...

PutMsg() could be rewritten so that if the message isn't MEMF_PUBLIC, it
copies the object. This will prevent MANY programs, but it won't prevent
all.

On the other half of the coin are the applications which use MEMF_PUBLIC
for everything, and become totally unprotected.

: It marks certain pages of memory invalid, which is basically all you need


: to implement MP on a basic level in AmigaDOS (discounting software
: issues).

Exactly. Enforcer just does it in a "global" sense. Localizing that
becomes a penalty, though.

Borge Noest

unread,
Jan 26, 1994, 12:33:01 AM1/26/94
to
In article <2hqhv5...@uwm.edu> gbl...@csd4.csd.uwm.edu (Gregory R Block) writes:
>On the other hand, this -ISN'T- true. IF the AmigaOS had VM and MP, it
>would still be relatively quick. Enforcer does a great deal of the work
>of MP, it just doesn't go the last mile; but in processing terms, it's
>almost as intensive.

Duh?
Have you looked at implementing protection under Exec?
I have; I have a working library that will keep memory away from other
tasks. Enforcer is not even _close_ to doing 'a great deal of the work of
MP', it's just a lovely debugging tool that will punish you when you screw
up, unlike 68040.library which does not.

I don't claim to have all solutions or know all problems with MP and Exec,
but from my standpoint the problem is the shared memory addresses between
all tasks. With UNIX you just give the task you switch in its own view of
the universe. With EXEC all tasks have the same universe, so you either
have to change the universe when a task switch happens (makes a task switch
expensive), or you have to update each tasks view of the universe when a
change to the universe happens (like allocating or freeing memory which
makes that expensive).
I'm not sure which approach is the least expensive overall, but I have gone
for the first solution at the time (it looked like it was easiest).

>Greg
--
|/// bor...@stud.cs.uit.no (Boerge Noest) | Amiga B2000 \\\|
|// Box 218, 9001 Tromsoe, Norway | Remember to :-) when needed \\|
|/ The worlds northernmost university | Life is worth living. \|
#Disclaimer: This university does not speak for me.

Borge Noest

unread,
Jan 26, 1994, 12:45:10 AM1/26/94
to
In article <CK5M3...@news.Hawaii.Edu> jo...@uhunix.uhcc.Hawaii.Edu (John Engelhart) writes:
> BTW, with enforcer running, try and trash someone elses program..
>Yep, it's possible. :)

Ah, you'll like my mmu.library :)).

>| jo...@uhunix.uhcc.hawaii.edu / / (tm)|

Borge Noest

unread,
Jan 26, 1994, 12:52:23 AM1/26/94
to
In article <2i4cpo...@uwm.edu> gbl...@csd4.csd.uwm.edu (Gregory R Block) writes:
>Guardian is in stasis; as a development tool, it's fascinating. It's not
>functional yet, but even in its current state, performance is
>jaw-droppingly slower. Slower than MungWall and Enforcer put together.

You mean that tasks run slower when Guardian is active because
a) alloc/free gets slower
b) you would get task switch overhead if you got that far
It's not really the tasks that slow down. Using pools would probably help
alot on alloc/free issues.

>No, this isn't acceptable. And it's not even _DONE_ yet. And it's STILL
>not doing the job--it's only protecting unallocated memory.

Mind sharing some code? I still have to take over the memory system, and I
could do with some pointers (pun intended) to it. I do have the Gu<cough
cough> disassembly to go with, so I'm not all lost.

>Greg

Ralph Schmidt

unread,
Jan 26, 1994, 2:04:15 AM1/26/94
to
Bohuslav Rychlik <br...@andrew.cmu.edu> writes:

>So who here is convinced that adding memory protection to the OS now
>(without using the afore-mentioned method) would break
>backwards-compatibility to 2.04 programs? I don't know; it just still
>seems to me that it ought to be possible.

It's only possible by cooperative MP support...so only new programs
otherwise you break almost everything.

Mike Farren

unread,
Jan 26, 1994, 3:47:13 AM1/26/94
to
Bohuslav Rychlik <br...@andrew.cmu.edu> writes:

>So who here is convinced that adding memory protection to the OS now
>(without using the afore-mentioned method) would break
>backwards-compatibility to 2.04 programs? I don't know; it just still
>seems to me that it ought to be possible.

Nope, and here's the simple reason why: currently, an application
communicates with the system via the use of system calls and the Exec
Message interface. An Exec Message consists of a header, and a data
section (simplified explanation, here). That data section can be
anything the application (or the system library) desires. In fact,
many of the current Messages pass pointers to memory as part of the
expected data section - and those pointers can point to memory the
*calling* task owns, and which the system can subsequently modify.
Or, for that matter, any other task - and *that's* the problem.

There has been no commonly-accepted way of specifying that a given
block of memory is private to the task. MEMF_PUBLIC *might* have
been a way to do that, but because the definition of MEMF_PUBLIC has
always been ambiguous, many apps are *not* using it to indicate
"publicly accessible" memory. And because there is no consistency
there, the possiblity (indeed, the certainty) that otherwise normal
Amiga operations will cross task-owned memory boundries utterly
prevents any reasonable memory protection scheme for applications
up to the present point.

Not only that, but with the current design, it's entirely possible
for a user application to modify *system* memory - and some hacks
depend on that ability, and protecting system memory is, perhaps,
the most important thing MP will give you.

--
Michael J. Farren far...@netcom.com

"Remember that good diction reflects so well on you, so practice all
your vowel sounds by saying "AAAEEEEIIIIOOOOUUUUU!" - Animaniacs

Mike Noreen

unread,
Jan 24, 1994, 2:54:24 AM1/24/94
to
In the message * Re: THREADS, PROCESSES AND TASKS (YET * Ezra wrote:

EAS> I quite agree :-). AmigaDOS in terms of the built-in functionality of
EAS> the OS is at a lower status than OS/2.. (altho closer to OS/2 than
EAS> MSDOS :-))

True, but the comparison being made wasn't between MS-DOS and OS/2, it
was between MS-DOS and Windows - two OS's the Amiga OS beats hands
down. See for yourself:

>> : > I think AmigaDOS is somewhere between MS-DOS and Windows.

OS/2 is bigger, has more features, and is slower than AmigaOS, but
Windows and System7 is just plain bigger and slower...

EAS> | Ezra Story | eas...@gold.cs.rit.edu | Ezy (IRC) | ************** |

MVH: Mike Noreen InterNet: rad...@p14.anet.bbs.bad.se
FidoNet: 2:201/411.14

--- Spot 1.2b Unreg.

Mike Noreen

unread,
Jan 24, 1994, 3:18:05 AM1/24/94
to
In the message * Re: THREADS, PROCESSES AND TASKS (YET * Jerry wrote:

JS> of GNU code running : on the Amiga, is that general purpose enough for
JS> you? :

JS> No. It's a bunch of development tools.

So is memory protection. A development tool.

JS> | JERRY J. SHEKHEL | Molecular Simulations Inc. | Cowboy Junkies,

John Engelhart

unread,
Jan 26, 1994, 2:52:43 AM1/26/