68k details

[idrougge]

Originally Posted by meynaf

If these so great multitasking systems were so cool, why did they just fade out ? How to check them now ?

You write this on an Amiga forum? Seriously, Meynaf?

[touko]

If these so great multitasking systems were so cool, why did they just fade out ? How to check them now ? Because it's written on wikipedia then it is necessarily true ?

You can take for example OS9, it was a great real time multitasking os, way better than windows or some others .
They fade out because marketing for many of them .
Your arguments mean,windows is great because is still here .

[meynaf]

Originally Posted by idrougge

You write this on an Amiga forum? Seriously, Meynaf?

Yes, seriously. Why not ?

Originally Posted by touko

You can take for example OS9, it was a great real time multitasking os, way better than windows or some others .
They fade out because marketing for many of them .
Your arguments mean,windows is great because is still here .

You're taking my arguments the wrong direction.
(et encore un qui a essayé de me faire dire ce que je n'ai pas dit !)

Something might still be here even if not great.
But something really great doesn't completely fade out like this. It leaves nostalgy behind. Exactly like Amiga.

[plasmab]

I’m not really sure multitasking is relevant here. Unless you want to compare context switch time multitasking is an OS implementation detail.

[meynaf]

Originally Posted by plasmab

I’m not really sure multitasking is relevant here. Unless you want to compare context switch time multitasking is an OS implementation detail.

The devil is in the details...

[plasmab]

Originally Posted by meynaf

The devil is in the details...

Ok. Correct me where I go wrong. You can write a multitasking OS in C or Assembler. Pre-emptive or cooperative. What does CPU X vs CPU Y change aside from how performant the switch from process A to process B is? (lets ignore security for the moment).

EDIT: another way to put it would be to ask what the quantitative measurement would be for a multitasking OS on CPU X vs CPU Y?

[touko]

You're taking my arguments the wrong direction.

It was just an example, because you seemed to be saying if an os was good in the 90's, inevitably it should still be alive nowadays .
Sorry if i misinterpreted,but it's because you wasn't clear

(et encore un qui a essayé de me faire dire ce que je n'ai pas dit !)

Donc c'est bien que tu n'es pas toujours clair dans ton argumentation

[meynaf]

Originally Posted by plasmab

Ok. Correct me where I go wrong. You can write a multitasking OS in C or Assembler. Pre-emptive or cooperative.

You go wrong here
You can't write a multitasking OS in 100% C. There has to be some asm inside. Not much nowadays, but still some, and at the very core.

Originally Posted by plasmab

What does CPU X vs CPU Y change aside from how performant the switch from process A to process B is? (lets ignore security for the moment).

Well, you may have extra work to do, depending on the cpu family.
If you don't believe me, peek at the linux core sources, for how much workaround work they had to do for x86. I haven't had a look myself but i'm nearly ready to bet there's quite some of it.
This may make the task too complex and the OS writer wannabe bails out.
Why do you think all OSes that are out today are evolutions of much older things and nothing mainstream is written from scratch in spite the financial means todays actors have ?

Originally Posted by plasmab

EDIT: another way to put it would be to ask what the quantitative measurement would be for a multitasking OS on CPU X vs CPU Y?

I don't get exactly what you're asking here. I can't really give a quantitative measurement.

But here's how i see things.
On CPU X you can do the core OS in assembler.
On CPU Y you can't really because asm is PITA. Therefore you used a compiler for most of the stuff, and ended up with largely suboptimal code (because compilers are not as good as most people pretend).

Originally Posted by touko

It was just an example, because you seemed to be saying if an os was good in the 90's, inevitably it should still be alive nowadays .
Sorry if i misinterpreted,but it's because you wasn't clear

But this IS what i was saying !
F.e. The Amiga OS was good in the 90's and it's kinda still alive nowadays...
But what i'm NOT saying is that if an OS is alive nowadays it's necessarily good. Got it this time ?

Originally Posted by touko

Donc c'est bien que tu n'es pas toujours clair dans ton argumentation

C'est parce que j'ai à la faire en anglais...

[plasmab]

You can make the OS a high percentage in C. But ok. So your argument is simply that one assembly language is easier than another. That can be managed in other ways.

I think your argument is all about you are cool because you do everything in assembly language and everyone else isn’t.

You haven’t given an objective quantifiable measurement. You make it all subjective. One mans difficult is another mans trivial.

EDIT: the vast majority of BSD and Linux is C and they run on multiple CPUs

[plasmab]

For the record I don’t think any of your arguments are wrong ... even the being cool bit... doing an OS in assembly language is cool.. but i just don’t think it’s really relevant in the sense these are not scientific methods of comparing CPUs

[meynaf]

Originally Posted by plasmab

You can make the OS a high percentage in C. But ok. So your argument is simply that one assembly language is easier than another. That can be managed in other ways.

That can't be managed in other ways. If the assembly language isn't easy enough then it has to be encapsulated. And this isn't done for free.

Originally Posted by plasmab

I think your argument is all about you are cool because you do everything in assembly language and everyone else isn’t.

I don't do everything in asm.

Originally Posted by plasmab

You haven’t given an objective quantifiable measurement.

Who has ?

Originally Posted by plasmab

You make it all subjective. One mans difficult is another mans trivial.

There are things nobody will find trivial, really.

Originally Posted by plasmab

EDIT: the vast majority of BSD and Linux is C and they run on multiple CPUs

I din't say the vast majority wasn't C. Just that some important part wasn't.

Originally Posted by plasmab

For the record I don’t think any of your arguments are wrong ... even the being cool bit... doing an OS in assembly language is cool.. but i just don’t think it’s really relevant in the sense these are not scientific methods of comparing CPUs

There are no really scientific methods of comparing CPUs. Whatever comparison is done, is always biased in some way.

[plasmab]

Oh come on you can do better than this. You can! I’ll even argue your side because your failing completely.

1. You could time how long it takes to get a basic OS developed in each assembly language.

2. You can measure the the average time it takes to fix a bug in one vs the other.

3. You can measure the key code metrics on these operating systems (cyclomatic complexity, average subroutine length etc)

4. You can measure context switching time, time to service an interrupt etc.

There loads more. The subjective arguments are pointless.

[meynaf]

Originally Posted by plasmab

Oh come on you can do better than this. You can! I’ll even argue your side because your failing completely.

I'm not failing. A failure to do what ? To play chess with pigeons ?
And perhaps i could do better, but it's not worth the effort.

As for CPU comparisons, always remember this :
I keep asking for code comparisons, but, how odd, nobody feels like writing x86, arm, or whatever code.

Originally Posted by plasmab

1. You could time how long it takes to get a basic OS developed in each assembly language.

For this to be more than an approximation, a basic OS needs to be really developed for every assembly language. Do I have years to waste with doing that ? Nope.

Originally Posted by plasmab

2. You can measure the the average time it takes to fix a bug in one vs the other.

For this i must actually write them. Not going to happen.

Originally Posted by plasmab

3. You can measure the key code metrics on these operating systems (cyclomatic complexity, average subroutine length etc)

Do I have the source of several operating systems and the time to study them ? Nope.

Originally Posted by plasmab

4. You can measure context switching time, time to service an interrupt etc.

How ? Do i have access to several OS internals to do that ?
(Actually i have measured context switching time long ago in the past and all tested OSes performed very poor, even though AOS won by far.)

Originally Posted by plasmab

There loads more. The subjective arguments are pointless.

If there's loads more, then please write more. Because for now...

[plasmab]

Ok. So just keep asserting your opinion then but don’t expect anyone to listen.

[meynaf]

Originally Posted by plasmab

Ok. So just keep asserting your opinion then but don’t expect anyone to listen.

So now i have to change my opinion just for people to listen ? It's becoming better every day

[plasmab]

I am surprised 68000 beat ARM on fast interrupt latency though. I will measure this at some point.

[plasmab]

Originally Posted by meynaf

So now i have to change my opinion just for people to listen ? It's becoming better every day

No just back it up with some facts. I’m not even disagreeing here just think when you say “X is too difficult” that it’s bollocks. Too difficult for you maybe.

[roondar]

Originally Posted by plasmab

I am surprised 68000 beat ARM on fast interrupt latency though. I will measure this at some point.

Frankly, I'd be amazed if it is!

On the 68000, a simple interrupt that merely pushes/pops all registers will already take on the order of 300 cycles (this is including the 44 cycles the 68000 takes to serve an interrupt and the 20 cycles for the RTE, but does not include the variable latency caused by prefetch and all that jazz).

I can't imagine an ARMv2/v3 being slower, given it reads/writes 32 bytes from memory per cycle.

[plasmab]

Fast interrupt on ARM v2/v3 doesn’t push anything. Bank switched a stack pointer. That’s why I’m surprised.

[meynaf]

Originally Posted by plasmab

I am surprised 68000 beat ARM on fast interrupt latency though. I will measure this at some point.

You can measure that if you want. Comparison is meaningless but you will be happy because ARM will win.

Originally Posted by plasmab

No just back it up with some facts. I’m not even disagreeing here just think when you say “X is too difficult” that it’s bollocks. Too difficult for you maybe.

If it's too difficult for me, then someone else should do it ? Wake up ! Nobody does ! Can't you read ? I ask some code and get nothing ! Yes it's too difficult, not only for me - as nobody does write said code !

But maybe YOU want to write ARM or x86 version of that Bresenham algorithm i told about ?