Dave Needle on Amiga...

[Iggy]

thanks for the link. interesting vid. Of course the first comment is by that moron franko. Every time he talks he embarrasses himself.

For God's sake magnetic, get over it.
At least he never meddled in MorphOS.

[Iggy]

Oh, and as a quick note on the "we could open multiple copies of a program" comment.
As they former vendor of 68K based OS-9 systems, WE could run multiple instance of a program and only have ONE copy of it in memory with multiple user/data areas.

That's where you guys blew it.
Loose sloppy coding that created all those lovely guru meditation crashes.

Even without memory protection, our program were structured better and were always written for position independent addressing.

SO...there is still a currently update 68K version of OS-9 available while AmigaOS 4 struggles to convince everyone that it is an AmigaOS (which of course it is, Hyperion can even incorporate the entirety of OS3.1 into OS4 if it desires).

I'd still love to see a tight micro kernel based OS that uses position independent addressing with a good tight graphic user interface.

[Iggy]

The Amiga could do this too.
 

 
Amiga software was position independent.
 

Amiga addressing is rarely designed to be reentrant.
In fact some coders used the heinous practice of creating self modifying code..
That makes reentrancy virtually impossible.
And the OS doesn't manage this function leaving the task to "friendly" applications.
That why older Amiga (and Windows) apps sometimes cause the system to go bye-bye.
And most code on 68K and later machines is position independent (or at least position relative).

[Iggy]

Reentrant code is not solely a function of a compiler switch.
Many of us were actually using assemblers in the 80's.

In any case, it was not a common function of Amiga programs.
Although it is a great way to write modular threaded code

[Iggy]

That is irrelevant, you're blaming the OS for bad software.

And you are being dismissive.
I had to write reentrant code for the OS I was using.
It was required.
AmigaOS allowed for bad programming practices.
So, yeah, I'm blaming the OS.

But, on the other hand, you have a strong point.
The programmers were frequently self taught and not always schooled on a variety of issued that compromised what they were creating.

And the OS, left to its own, was as stable (maybe more so) then many alternatives.

[Iggy]

How could the OS detect or enforce it? Did you just run into problems if you ran more than one copy?

No, it is a required function.
It also explain why the OS wasn't ported to Intel platforms until the '386 was introduced. Not enough CPU power to pull of something that Motorola had been doing since the time of their 8 bit products.
It was also useful to be able to assign priority values to processes so that processes that didn't need too much CPU time didn't waste it.

[Iggy]

I do not understand, what function in OS9 forced you to write code in a pre-ordained way.
Should that function be added to AROS if it doesn't already have it?

No, we aren't talking Mac OS here, and AROS is based on the AmigaOS 3.1 API.
Why would you want to force AROS to do something that is optional.
The entire matter was much more important when memory was expensive.

[Iggy]

Required by who and how was that requirement tested for and enforced?

I've already explained this so I'll walk you through it again in more detail.
Under Microware's OS-9 task scheduling and the assignment data areas (which are separate  from program areas and will be multiple IF more then one process calls another program) are some of the kernal's primary activities.
Could you create non-reentrant code? Of course you could if you had a module that would never be called by more than one process.
And that would probably fall back to loading a second copy of that module if two processes called it.

But since the compilers were already designed for reentrancy AND the core of the operating system was optimized for it, you wouldn't have seen it very often.

You guys need to look at how a microkernel based OS is designed to work. It encourages specific programing habits.
I don't know if MorphOS relies as heavily on this, but I would not be surprised to see that it had been implemented.

You see, again, by separating program modules and data modules, you're optimized to implement reentrancy.

Now, short of loaning you a Pascal09 or Basic09 manual, or walking you through how you would set this up under C, I can't see how to explain this to you further.

[Iggy]

Just went back thru your posts..

Where exactly did you "explain this before?"

Where you said:



All that says is that it (whatever "it" is) is a required function and hints there is CPU overhead, but not why..

Here:

Doesn't seem to explain anything there...

This:

Again, nothing I see there is an explanation....

Not this:


That just implies you did it as a programmer, not that anything required it..

So, if you thought you had already explained it...

I'm not seeing it...

But the "I'm so much better than you and if I HAVE to explain it again" attitude is kind of funny...  

desiv

Good point.
Until I'd mention that the OS had several module classes, it would have been hard to explain while modular reentrant code was an advantage.
Plus you have the ability to load and unload module dynamically (and I really don't want to explain the advantage of that).
But actually its not that processor intensive and we were able to create some processes that were so generalized that they were never unloaded.
One early 6809 based point of sales system was composed of slightly less then 255 modules.
One low level clean up 'gnome' only got a processor slice every few seconds
but its presence made the system very stable.
Unless you've already experienced coding like this, its hard to explain the advantages.

Besides, this is WAY off topic.