THREADS, PROCESSES AND TASKS (YET
joe....@asb.com
> 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
: >
: > 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
>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
>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
>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
>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.
>
>>: 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
: 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
: >
: >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
: >:
: >: 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
>
>... 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
>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
: >
: >... 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
>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
>: >
>: > 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
: >
: >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
>: 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
>... 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
: 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
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
>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.
>
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
: : >... 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
>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
>In article <2hk490$9...@sol.ctr.columbia.edu>, Jerry Shekhel (je...@msi.com) wrote:
>: AmigaOS gains its efficiency by sacrificing major OS functionality. This
>
>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
>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.
>
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
>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
> 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
>
>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
: >
: >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
>: 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
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
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
>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
>>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
: 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
> 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
: >
: >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
Protection (M.. by John Enge...@uhunix.uh
> 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
: 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
>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
> 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
>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
>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
>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
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
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
[much snipped]
>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.
Oh, ok. Now it's clearer.. Yea, I'd agree, if it had it from the
beginning it wouldn't impact system performace that much. Lots of
ways to speed it up. For example, on a '40 you'd allocate chunks of
memory to a process in 4K increments. To speed things up, you'd allow
the process to write anywhere inside that 4K, instead of checking
exactly where it's reading. So, while techincally the process might
only own the first 8 bytes, it could write anywhere inside the 4K.
That's just one perspective on how to make it run quickly. Heck, is
it even possible to check exactly where it's trying to read? But
anyways, agreed: Not that big of a performance hit.
________
-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): "Slogans(r)" |
-------------------------------------------------------------------------
ba...@admin1.memst.edu
means slower task switching and you have to rebuild arexx and
message ports. The main idea of the OS is to share memory, Libs,
mesages. That means having one copy. If you go to memory protection
you have to make a copy and pipe it to the other program. That
means having a slower OS. I for one like the way AMIGADOS
runs and if I could change anything it would be for the amiga
to have better programers to not make buggy programs.
Memory protection is not what everyone thinks it is. I
have seen every machine crash, even a VAX so in the end
there is no real safe guard.
Jerry Shekhel
:
: 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:
:
AmigaOS beats MS-DOS hands down, yes. AmigaOS is better than Windows in
some respects, worse in others.
:
: OS/2 is bigger, has more features, and is slower than AmigaOS, but
: Windows and System7 is just plain bigger and slower...
:
No, Windows and System 7 have features AmigaOS lacks. The reverse is
also true. There is no system that's clearly superior. It depends on
your needs.
: MVH: Mike Noreen InterNet: rad...@p14.anet.bbs.bad.se
Jerry Shekhel
:
: 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.
No. Besides being very useful during development, memory protection
enhances system stability, and all users benefit from that.
Gregory R Block
: Duh?
No. Me Greg, you Victor. Eh, Borge.
: Have you looked at implementing protection under Exec?
Yes.
: 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'll contend this:
A great deal of MP is dealing with the MMU table. A great deal
of MP's speed is tied up within that MMU table. So, from THIS
perspective, Enforcer does most of the work of an MP system, and its
performance is a thumbnail of that.
: 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).
Yes. It gets VERY expensive under Guardian. I had to write
AllocMem/FreeMem lookalikes, and it made me wish I was running MungWall,
even if it was protected.
: 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).
I'm not so sure. Guardian still gets some of my time, but not a lot. I
-DO- wish that C= had made Guardian Angel a reality. REGARDLESS of its
problems, the idea of protecting free memory is a good one.
Gregory R Block
: a) alloc/free gets slower
Oh, yeah. Like, much. Slower than MungWall, to say the least.
: 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.
I imagine it would help a lot. :)
: 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.
I began with Enforcer, and went from there. It's just Enforcer with an
AllocMem() and FreeMem() replacement that alter that MMU table.
And I'm not letting the code out until it's done. Which may be a while.
Naturally, once it's out, I'll source-release.
Ezra A Story
>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.
Thanks for the quote which came from nowhere. I couldn't find the article
I responded to, but I'm almost positive that he said "OS/2" and not
"Windows". (why didn't you just copy the quote I responded to above?)
Anyway, what this has to do with anything I don't know.. I made my point
pretty clear, whether it was in sync with the original comment or not. :-)
>OS/2 is bigger, has more features, and is slower than AmigaOS, but
>Windows and System7 is just plain bigger and slower...
:-)
--
| Ezra Story | eas...@gold.cs.rit.edu | Ezy (IRC) | ************** |
Mike Farren
>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.
You're right - it will prevent many programs ... from working :-)
The problem is that in a number of cases, you don't know what the object
you have to copy *is*, or if it's even copyable - suppose it's a pointer
to a 1M block of memory on a 2M Amiga, how are you to copy that? Worse,
many operations pass pointers as conveniences only, and expect the actual
operation to be performed on the actual block of memory referenced. So
you'd not only have to copy the object, you'd have to copy it *back*.
Sometimes. Other times, you wouldn't *want* to copy the object back...
The current state of the Amiga OS is simply too confused to allow MP
to work in any particularly meaningful way. And to change the things
which cause the confusion would, unfortunately, have dire effects, both
on current applications, and on the very nature of the OS operation.
You'd lose speed, for one thing...
Teler Eyal
|> Wait. If you add memory protection you end up with unix like. This
|> means slower task switching and you have to rebuild arexx and
|> message ports. The main idea of the OS is to share memory, Libs,
|> mesages. That means having one copy. If you go to memory protection
|> you have to make a copy and pipe it to the other program. That
|> means having a slower OS. I for one like the way AMIGADOS
|> runs and if I could change anything it would be for the amiga
|> to have better programers to not make buggy programs.
|> Memory protection is not what everyone thinks it is. I
|> have seen every machine crash, even a VAX so in the end
|> there is no real safe guard.
It would still be nice to have MP as a standard option, at least so that
developers would be forced to make their programs compatible with it.
Make PUBLIC memory mean something, so future programs will use it correctly.
Current programs could still be run with MP turned off.
Since bugs exist in every program, it would be nice if there was a way to
protect from them. This way we'll at least have an option to keep the
Amiga up and running even with those programs who misbehave.
Besides, what better way to force C= into putting CPUs with MMUs than
saying we do need MP. (Saying we don't need MP certainly won't help here.)
VM would also be nice once we have that MMU :)
ET
--
Borge Noest
>: Mind sharing some code?
>AllocMem() and FreeMem() replacement that alter that MMU table.
Hm... great minds think alike? :)
Mine actually requires Enforcer to be running. I found it to be much easier
to just dump the burden on it :)).
As more programs use pools I think the overhead would be acceptable.
Borge Noest
>: Enforcer is not even _close_ to doing 'a great deal of the work of
>: MP'
>I'll contend this:
> A great deal of MP is dealing with the MMU table. A great deal
>of MP's speed is tied up within that MMU table. So, from THIS
>perspective, Enforcer does most of the work of an MP system, and its
>performance is a thumbnail of that.
I'm not sure if I get your point. Enforcer will never _do_(read: change)
anything with the mmu tables (with the exception of address $4 which you
should read only once in your program) once they are set up. (Ok, so it
does to handle hits, but that's not an argument.)
If you have a 68040 then 68040.library will set up mmu tables that does the
same mapping as Enforcer, but it wont complain about the address in use
going nowhere. It will still only cache descriptor data for 256K at a time.
I don't see what speed difference Enforcer makes.
[allocate/free with MP]
>Yes. It gets VERY expensive under Guardian. I had to write
>AllocMem/FreeMem lookalikes, and it made me wish I was running MungWall,
>even if it was protected.
The code in Guardian isn't exactly tuned for speed, more for memory use.
And it's badly optimized too.
>the idea of protecting free memory is a good one.
Agree.
Bohuslav Rychlik
Memory Protectio.. by Mike Far...@netcom.com
>
> >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.
Ah, now here's finally a good explanation. And I can understand the
difficulty here - under an MP scheme, if you pass a pointer to another
task and that task takes over, getting different memory restrictions,
that pointer is now useless.
Here's another question - is there any way to tell whether a message is
a pointer or not? From what you said, I gather there is no typing at
all, so probably not.
And a second question - is it common for system software to pass
pointers to its own memory area to other tasks? (I am thinking here
that maybe only OS memory protection could be achieved, but I am
guessing the answer to my question is yes, and therefore the project
impossible.)
Bohuslav Rychlik
> means slower task switching and you have to rebuild arexx and
> message ports. The main idea of the OS is to share memory, Libs,
> mesages. That means having one copy. If you go to memory protection
> you have to make a copy and pipe it to the other program. That
> means having a slower OS. I for one like the way AMIGADOS
You don't always have to COPY messages to pass them in an MP OS. There
are MP OSs that pass messages by paging the message-containing memory
with the MMU, so no copy is made. Only the memory area ownership is
changed.
So I see the "memory protection on the Amiga would be slow because
messages would have to be copied" argument as insufficient and not that
relevant. What is much more relevant is that (apparently, from what I
gather here on the net) Amiga tasks regularly pass pointers to their own
memory in these messages to other tasks, which then access this memory.
THAT is the problem, if I understand correctly.
Borge Noest
>and don't forget the apps that would break because they assume that
>the memory alignment is 8....a fault by CBM that they haven't added
>a Memoryalign field in the ExecBase.
Have you looked at the latest AllocMem() autodoc?
It actually says that memory is _longword_ aligned, not quadword.
AllocVec() says it uses the same rules as AllocMem() and AllocVec() will
only add 4 bytes to the size, call AllocMem() and put the size in front of
the allocated mem: Only longword aligned here too! (That was when I shaked
my head and went looking for 'alignment is 8' in the autodoc.)
>Ralph Schmidt la...@uni-paderborn.de
Gregory R Block
: Hm... great minds think alike? :)
: Mine actually requires Enforcer to be running. I found it to be much easier
: to just dump the burden on it :)).
Heh! ;) Pretty cool. But how do you manage to "get along" with
enforcer's MMU table?
: As more programs use pools I think the overhead would be acceptable.
Which isn't true of the present, but will hopefully be true of the future.
Neil Gall
: So I see the "memory protection on the Amiga would be slow because
: messages would have to be copied" argument as insufficient and not that
: relevant. What is much more relevant is that (apparently, from what I
: gather here on the net) Amiga tasks regularly pass pointers to their own
: memory in these messages to other tasks, which then access this memory.
: THAT is the problem, if I understand correctly.
But if you pass a pointer to another task at all, it should be a pointer
to PUBLIC memory. If you allocated private memory, you indicated at
that point that you didn't want anyone else to see it. If you want to
pass it to another task, even via a pointer in a message, you allocate
PUBLIC memory. Simple.
--
Neil Gall Queensferry Telecoms Operation
ne...@hpqtdya.sqf.hp.com Hewlett-Packard Ltd.
031-331-7895 South Queensferry, Scotland
Ralph Schmidt
>You don't always have to COPY messages to pass them in an MP OS. There
>are MP OSs that pass messages by paging the message-containing memory
>with the MMU, so no copy is made. Only the memory area ownership is
>changed.
>So I see the "memory protection on the Amiga would be slow because
>messages would have to be copied" argument as insufficient and not that
>relevant. What is much more relevant is that (apparently, from what I
>gather here on the net) Amiga tasks regularly pass pointers to their own
>memory in these messages to other tasks, which then access this memory.
>THAT is the problem, if I understand correctly.
The most people here seem to forget that the MMU alignment is 4k/8K for
the 68040...do you always want to check in a list if a buserror
is ok ? That's a major slowdown.
The other solution would be that every alloced memory is aligned to
4k/8K and now everybody should see how much memory will be lost...
and don't forget the apps that would break because they assume that
the memory alignment is 8....a fault by CBM that they haven't added
a Memoryalign field in the ExecBase.
BTW..a 4k aligned memory system woudn't prevent that messages could
be placed on every word aligned address.
.........
Small Example:
4k Page Start:
Data from Task x
Data from Task y
Msg from Task z
4k Page End:
If you would declare this page as shared...Task z and the msg receiving
Task Fubar could modify every byte in this page. No..MP.
If you wouldn't declare this page as shared...the msg receiving Task
would cause a lot bus errors because he accesses illegal memory...now
the bus error exceptionhandler has to check if this access was legal.
At this moment the system is in the Supervisor Mode...all ints
disabled and the processor has to scan a large list
=> system freezed and big slowdown.
Conclusion:
The only practible way would be to copy the msg but:-B
1) The msg length field is almost as unusable as the MEMF_Public flag
2) The msg contains ptrs
Forget it...it's not possible without breaking every application.
The only way is cooperative MP. Currently Borge Noest is working
on something like that.
Ralph Schmidt
>In article <2iaov7$s...@klee.uni-paderborn.de> la...@klee.uni-paderborn.de (Ralph Schmidt) writes:
>>and don't forget the apps that would break because they assume that
>>the memory alignment is 8....a fault by CBM that they haven't added
>>a Memoryalign field in the ExecBase.
>Have you looked at the latest AllocMem() autodoc?
>It actually says that memory is _longword_ aligned, not quadword.
>AllocVec() says it uses the same rules as AllocMem() and AllocVec() will
>only add 4 bytes to the size, call AllocMem() and put the size in front of
>the allocated mem: Only longword aligned here too! (That was when I shaked
>my head and went looking for 'alignment is 8' in the autodoc.)
I know that AllocVec is Longword Aligned but allocmem is longword
aligned ? well..wait..lemme load the Autodocs....you're right..
i check the 2.04 includes now...here there's no comment.
They must have changed that in the docs.
If AddMemList() is not guranteed to start the memory quadword aligned
because it's not written somewhere the long comment is correct.
(Well it does that so all is still quadword aligned anyway:-B).
Borge Noest
>: Mine actually requires Enforcer to be running. I found it to be much easier
>: to just dump the burden on it :)).
>Heh! ;) Pretty cool. But how do you manage to "get along" with
>enforcer's MMU table?
I just change the descriptors from read&write to read only or indirect to
Enforcer's global illegal address descriptor as needed when tasks switch.
John Engelhart
>Here's another question - is there any way to tell whether a message is
>a pointer or not? From what you said, I gather there is no typing at
>all, so probably not.
Nope, not possible. The two programs passing messages to each other
give context to the data enclosed in the message. To the OS, it just
looks like a bunch of data.
>And a second question - is it common for system software to pass
>pointers to its own memory area to other tasks? (I am thinking here
>that maybe only OS memory protection could be achieved, but I am
>guessing the answer to my question is yes, and therefore the project
>impossible.)
I think it's a VERY common practice to pass pointers to memory that
only the task owns. It's hard to say, most software will only use the
system libraries and pass messages to those libraries. If the
libraries run under the context of the task, then there's not much of
a problem. If calling the libraries causes the system to go into a
'system' context, then there might be some problems. It's really hard
to say who would have problems and why. Very case by case.
________
-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): "A Real American Loser, G.I. Jobless!" |
| Includes Wrist-Slitting Battered Wife Action Figure! |
-------------------------------------------------------------------------
Gregory R Block
: I just change the descriptors from read&write to read only or indirect to
: Enforcer's global illegal address descriptor as needed when tasks switch.
Enforcer doesn't bitch??? I had assumed it would; so I went from scratch.
Jack Radigan
>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.
Those are examples?
Maybe Greg doesn't have a clue to what the Amiga is lacking (I think
he does though).
You, however, don't even have a clue *what* consitutes an OS or is a
functional member of one.
-jack-
Jack Radigan
>: >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 don't have an OED here, but the Scribner-Bantam I do have has "greater in
quantity" as the first entry for "more" and "less" has "not so great in
quantity".
Sure looks like "not more" is equal to "less" just as "not less" is equal
to "more"...
>I can't believe I have to explain this to someone who uses computers and
>claims to do some programming.
I'm well aware of how "not more" equates to "equal or less" when you're
discussing things in the context of relational operators as it applies to
computer logic.
I'll keep that in mind the next time I read one of your posts...
-jack-
Jack Radigan
>ENOUGH! THis has got to be the most ridiculous thread, even for advocacy.
Oh, and who anointed you as NetGod of All that is Rational?
>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)
And just what is "if its not one its the other"?
Or are you just apostrophe-challenged?
>"Not More" means whatever is not "More" :-). What is NOT more? *Less OR
>the same*, fucking dolts. :-)
Now, there's a real gem of intelligent discourse...
-jack-
Jack Radigan
> Oh, ok. Now it's clearer.. Yea, I'd agree, if it had it from the
>beginning it wouldn't impact system performace that much. Lots of
>ways to speed it up. For example, on a '40 you'd allocate chunks of
>memory to a process in 4K increments. To speed things up, you'd allow
>the process to write anywhere inside that 4K, instead of checking
>exactly where it's reading. So, while techincally the process might
>only own the first 8 bytes, it could write anywhere inside the 4K.
I don't see where the benefit is. The MMU still has to check for an
illegal reference each time, be it at page level or address level
granularity. There might be some measure of improvement since you don't
have to process the lower 12 bits in the address, but that still leaves
20 other bits that are used for page addressing and have to be checked.
If I've missed something here I'd appreciate a clarification.
-jack-
Ezra A Story
>eas...@cs.rit.edu (Ezra A Story) writes:
>
>>ENOUGH! THis has got to be the most ridiculous thread, even for advocacy.
> Oh, and who anointed you as NetGod of All that is Rational?
Me, of course!
> And just what is "if its not one its the other"?
A vocabulary spasm :-). I guess my point was that you guys seem to take
all this stupid bickering too much to heart. Anyone should be smart enough
to realize that when you start arguing about vocabulary, you've already
mangled the debate far enuff that it just isn't worth it.
> Or are you just apostrophe-challenged?
No, I'm patience-challenged.. I knew I shoulda stayed out of this because
now you've got me posting to the same damn thread. :-)
>>"Not More" means whatever is not "More" :-). What is NOT more? *Less OR
>>the same*, fucking dolts. :-)
>
> Now, there's a real gem of intelligent discourse...
Just because you use a word with greater than 5 letters doesn't mean it's
not an insult, or thats it's intelligent. (Oooo.. he used the word
"discourse"... +5 pts... NOT) :-)
Jack, take a pill. It wasn't meant to be intelligently presented. It was
meant to be as rude and annoying as possible. I think I succeeded. :-)
Ezra A Story
The '40's MMU has only 4K and 8K granularity if I remember correctly.
If you used address level granularity for memory allocations, you'd have
to generate page faults when a task accessed a page that has some of
another tasks's memory in it, even tho that task might also have memory it
can access within that page. If you limit allocations to page boundaries,
you can mark a page as accessable from a certain task and not worry about
handling cases where tasks share a page of memory.
I guess it doesn't reduce of the general overhead of using an MMU, but it
reduces page faults that would occur even when the access is not illegal
(according to the OS).
John Engelhart
Well, as I said in one of the earlier messages in this thread, my
knowledge on the MMU is horribly inadequate. BTW, if anyone off hand
has the phone # for motorola and the order #'s for the 68040 manual
and and books by motorola on the MMU's, please email me. Or, any
books published by publishers other than motorola or articles on the
68K MMU would be appreciated.
Now, about what I said: I was working under the assumption (bad,
yes, I know.. :) that the MMU was able to cache a number (the number
64 pops into my mind, but that might be wrong) of MMU translation
'attributes' (probably the wrong term, hopefully you can grok from
context). But anyways, I figured the following: If the memory
protection AllocMem() function pooled memry allocations on 4K
boundrys, it could use the Address Translation Cache to do most of the
managing of illegal accesses.
With some more thought, this becomes a nasty little problem. :)
Each context switch you'd have to update all those tables to reflect
the new task context's memory access privilages. All I can say is
OUCH. Again, I don't have any docs on the MMU, am I attacking the
problem the wrong way?
The basic principle I was trying to get across was that you should
try to pool memory allocations to try to speed things up.
________
-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): "Let us dream for you." |
-------------------------------------------------------------------------
Borge Noest
>: I just change the descriptors from read&write to read only or indirect to
>: Enforcer's global illegal address descriptor as needed when tasks switch.
>Enforcer doesn't bitch??? I had assumed it would; so I went from scratch.
It does bitch if you try to quit it or reset (tries to FreeMem() what I
have allocated and fails miserably).
Jerry Shekhel
: >
: >"Not More" means whatever is not "More" :-). What is NOT more? *Less OR
: >the same*, fucking dolts. :-)
:
: Now, there's a real gem of intelligent discourse...
Intelligent discourse doesn't work with someone who is convinced that "not
more" equates to "less", and then flames people for disagreeing with him. I
really think it's time to throw in the towel on this one, Jack. You lost;
you can save yourself further embarrassment by not posting any more about it.
: -jack-
--
+-------------------+----------------------------+---------------------------+
| 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... |
+-------------------+----------------------------+---------------------------+
Gregory R Block
: Or are you just apostrophe-challenged?
Apostrophically challenged, please. And it's not more interesting than
the rest of these posts. ;)
Gregory R Block
: Intelligent discourse doesn't work with someone who is convinced that "not
: more" equates to "less", and then flames people for disagreeing with him. I
: really think it's time to throw in the towel on this one, Jack. You lost;
: you can save yourself further embarrassment by not posting any more about it.
In the interests of posting not more, I'd like to say that your posts are
not more interesting or intelligent than your usual.
Ezra A Story
>eas...@cs.rit.edu (Ezra A Story) writes:
>
>anything.
True... (backpeddle backpeddle).
> Resorting to the use of "fuck" to make your point, doesn't...
Point? there was a point? I think I better stop posting to my thread before
I *really* start sounding like an idiot (too late :-)).
>>Jack, take a pill. It wasn't meant to be intelligently presented. It was
>>meant to be as rude and annoying as possible. I think I succeeded. :-)
>
> Rude? Yes. Annoying? Hardly. Intelligent? Still waiting...
Oh hell, 1 for 3 isn't that bad... :-P