Next gen Amiga

[Thorham]

Originally Posted by meynaf

That's not what i understood from what you wrote a few posts earlier

Somehow I didn't understand exactly what you meant

Originally Posted by meynaf

So i need my own test program or not ?

No, you don't, but you can still use the script language for automating things if you want.

Originally Posted by meynaf

What's needed to run that calculator ?

Just what's in the archive I gave you earlier. You didn't try just double clicking the icon?

Originally Posted by meynaf

As hard as writing a new OS is, no more no less.

Seems more time consuming than hard, actually.

[meynaf]

Originally Posted by Gorf

you are right: SIMD in (a new) instruction set are a must.

Nope this is the opposite of what I wrote

Originally Posted by Gorf

Edit: ah - "lot more sexy" instead of "not more sexy" - i misread the first time ;-)
YES: it is fascinating but a lot of work....

Imagine executing legacy code with an IPC of up to 1024, similar to the power of a GPU.
But no need to write code especially for it.
And next generation accelerates old code altogether.

THIS is how i see SIMD. NOT stupid ISA extensions that are obsolete even before they are really used.

Originally Posted by Gorf

am I wrong or is AROS not offering exactly that?
Or would you both consider it as to far off already?

AROS on 8Mhz 68000 ? Are you ok ?

Originally Posted by Thorham

Just what's in the archive I gave you earlier. You didn't try just double clicking the icon?

There was an icon ?

Originally Posted by Thorham

Seems more time consuming than hard, actually.

I guess it's a nice mixture of both...

[Gorf]

Originally Posted by meynaf

AROS on 8Mhz 68000 ? Are you ok ?

OK, let me reword this:

Would it be easier (less time consuming) to fix and improve AROS or to start from the scratch?

[meynaf]

Originally Posted by Gorf

OK, let me reword this:

Would it be easier (less time consuming) to fix and improve AROS or to start from the scratch?

For this task i'd choose to start from scratch.

[Megol]

Originally Posted by meynaf

Smaller, easier to support in hardware, faster, is to just drop 64-bit support.

Smaller: yes. A few percent at most.
Not easier to support in software.
Faster: in a pure speed-demon design, yes. A few percent lower latency in adder path and about one clock lower latency for multiplication (unless a 32x32->64 instruction is supported). In practice no.

And the downside: whenever you want to do additions on 64 bits you need two instructions with an additional clock latency. Or at least 6 instructions to do a 64x64->128 multiplication, this is being overly generous by assuming ternary addition instructions with carry support.

Less orthogonal ???
No 64-bit cpu in the world is orthogonal, and for a good reason.
But you can have orthogonal, easy-to-use, 32-bit cpu.

Why would 64 bit have anything to do with being orthogonal?

The idea that a 32 bit processor is easier to use than a 64 bit processor is just ludicrous. And you, as usual, don't give any reason why that would be.

For 64-bit there are better ways.
For data, merge 2 32-bit instructions together to do a single 64-bit one. As an advantage, your code will run regardless if this is the 32-bit or the 64-bit of your core.
For addresses, use the trick i mentioned before.

You want to waste more instruction bytes to do something, you want to complicate hardware making it slower and you don't see the problem.

But programming is a pain in the a$$. Sorry, but no.
Having to use 4 or 5 instructions to do the job of one is a no-go today. But there are still people believing in RISC lies...

The no-go place that the most popular processor architecture is in?

I wonder what construct would need 4-5 instructions when the 68k only need one? MOVEM possibly. However I can see many common operations where a 68k would need two+ instructions that map to one C/RISC instruction.

And you again doesn't give any example of _why_ it would be a pain in the ass.

It would just be horrible to code on. Besides, it would have very poor code density.

Everything but 68k is apparently horrible.

[meynaf]

Originally Posted by Megol

Smaller: yes. A few percent at most.

A few percent, for about everything being twice the size ?

Originally Posted by Megol

Not easier to support in software.

I wrote "easier to support in hardware".
But anyway of course yes it is. Software is always easier to make when it has less things to handle.

Originally Posted by Megol

Faster: in a pure speed-demon design, yes. A few percent lower latency in adder path and about one clock lower latency for multiplication (unless a 32x32->64 instruction is supported). In practice no.

You forget about quite a lot of things that actually make it slower.
Remember you have to move twice the data amount for every pointer you touch (and some data). Means more pressure on the caches. Means slower.
And i'm not speaking about routing latencies that will not help (even though this is more important in fpga than in asic).

Actually i wouldn't be surprised if some x86 programs are slower in 64-bit than in 32-bit in spite of this mode having twice the registers.

Originally Posted by Megol

And the downside: whenever you want to do additions on 64 bits you need two instructions with an additional clock latency.

This is easy to fix and i explained how.
And anyway the case is too rare to account for anything significant.

Originally Posted by Megol

Or at least 6 instructions to do a 64x64->128 multiplication, this is being overly generous by assuming ternary addition instructions with carry support.

You speak about a nonexisting downside. When did I last need 64x64->128 multiplication in code ? Oh yes : never !

Originally Posted by Megol

Why would 64 bit have anything to do with being orthogonal?

Because for being 64bit you have to remove things.
There are quite a few operations that are available for 32-bit x86 that 64-bit x86 does not support. Try to guess why.

Originally Posted by Megol

The idea that a 32 bit processor is easier to use than a 64 bit processor is just ludicrous.

That brings nothing to the discussion. You're just coming at the limit of name-calling.

Originally Posted by Megol

And you, as usual, don't give any reason why that would be.

Nope.
First, you're at the limit like above.
Second, I told it already. Did you read and understand what i wrote ?
But ok, here it is again.
Try to encode 68020 with added 64-bit. You will quickly see that you have to either lose orthogonality or remove some features. Simply because there is not enough encoding space to fit this extravagant "upgrade".

Originally Posted by Megol

You want to waste more instruction bytes to do something,

Since when are you concerned about wasting instruction bytes ? Your proposition is much worse than this !
Again, be realistic. 64-bit datatype is rare even in 64-bit programs. So these few bytes are more than compensated by having a better instruction set.
You want a proof ? Encode your thing, i encode mine. We both write a significant sized routine and compare the size... Oh, well. Something tells me you're not gonna do this.

Originally Posted by Megol

you want to complicate hardware making it slower

Nope.

Originally Posted by Megol

and you don't see the problem.

If you see a problem, explain it.

Originally Posted by Megol

The no-go place that the most popular processor architecture is in?

First, being popular has never meant being technically good.
Second, no popular processor architecture is really there anymore.

Originally Posted by Megol

I wonder what construct would need 4-5 instructions when the 68k only need one? MOVEM possibly. However I can see many common operations where a 68k would need two+ instructions that map to one C/RISC instruction.

4-5, yes, that does exist, maybe rare enough, but for common instructions 3 is easy to find.
Something like ADD.W D0,(A0)+.
Or BSET #0,(A1).

Of course instructions exist that may need up to 8 and more. Think about something like BFINS.

But even if it's just 2. That means twice the amount of instructions to decode and execute. By definition it can not be faster. Because risc or cisc, both can reach same ipc (actually perhaps more for cisc because code is smaller and therefore the icache can provide more of them per clock).

Originally Posted by Megol

And you again doesn't give any example of _why_ it would be a pain in the ass.

I have, but why would I do that again ? Seems you just don't read what I write and repeat the same wrong things over and over.

Originally Posted by Megol

Everything but 68k is apparently horrible.

That's true. But you need to write enough code to know that. And i'm still waiting for any code comparison we could have made.

I know by experience that only 68k can make a few things possible, like disassembling megabytes of code and alter that to make it work on another platform, or writing entire apps (of a significant size) in asm.

Work is always easier when you have the right tool for the job.
The 68000 has been designed after doing statistical studies of existing programs.
So would I if asked to design my own. I even already have such statistics.
Did you do that ? If not, you can not speak about what's useful in programs and what's not, period.

[Dunny]

Having 64bit instructions makes my job much easier - audio processing. 64 bit floats are handled atomically for starters and having extra RAM immediately addressable is a godsend for working with multi-gigabyte instruments.

[Thorham]

Originally Posted by meynaf

There was an icon ?

Originally Posted by meynaf

I guess it's a nice mixture of both...

Still doesn't seem too difficult, especially since I have an OS book.

Originally Posted by Gorf

Would it be easier (less time consuming) to fix and improve AROS or to start from the scratch?

Starting from scratch might not be a bad idea, unless you're running it on a recent CPU. Assuming there's nothing wrong with AROS, there's probably nothing to really fix.

Originally Posted by Megol

Everything but 68k is apparently horrible.

For writing in assembly language, probably.

[jPV]

Originally Posted by Thorham

Assuming there's nothing wrong with AROS, there's probably nothing to really fix.

Heh, ask MorphOS developers why they don't do code exchange with AROS anymore

[meynaf]

Originally Posted by Dunny

Having 64bit instructions makes my job much easier - audio processing. 64 bit floats are handled atomically for starters and having extra RAM immediately addressable is a godsend for working with multi-gigabyte instruments.

64-bit floats are different to the normal instruction set.
Besides, you're probably not coding your audio processing software in asm so it is not relevant.

[meynaf]

Originally Posted by Thorham

Still doesn't seem too difficult, especially since I have an OS book.

An OS book ? Is it "How to write an operating system in ten lessons" ?

[Thorham]

Originally Posted by jPV

Heh, ask MorphOS developers why they don't do code exchange with AROS anymore

Is it that bad?

Originally Posted by meynaf

64-bit floats are different to the normal instruction set.

Indeed. Even old 16bit FPUs can handle 64bit (and 80bit!) floats.

Originally Posted by meynaf

An OS book ? Is it "How to write an operating system in ten lessons" ?

It's the book Operating System Concepts.

[Gorf]

Originally Posted by Thorham

It's the book Operating System Concepts.

By Abraham Silberschatz

This book is good, but too much centered on standard kernel OSes - it gives a good insight into NT, BSD, Linux and even a little bit microkernals, but other concepts like SASOS and exokernel are missing.

Following this book you would probably end up with just an other posix-clone with monolithic kernel...

Without single address space and a exokernel it is not Amiga-like.

[Dunny]

Originally Posted by meynaf

64-bit floats are different to the normal instruction set.
Besides, you're probably not coding your audio processing software in asm so it is not relevant.

Yeah, we are - parts of it that the compiler can't handle, at least

[Thorham]

Originally Posted by Gorf

Following this book you would probably end up with just an other posix-clone with monolithic kernel...

It's more about knowing the concepts involved then about implementing everything in the book as is.

Originally Posted by Gorf

Without single address space and a exokernel it is not Amiga-like.

For me, Amiga like wouldn't be the goal of writing a new OS anyway. We already have AOS, AOS 4, AROS and MorphOs. Seems more interesting to try something new.

[Gorf]

Originally Posted by jPV

Heh, ask MorphOS developers why they don't do code exchange with AROS anymore

Why don't they? Attitude? Bad code quality? legal reasons?

If there is "nothing wrong with AROS" conceptually, than it would make sense to optimize speed relevant parts.
We are talking about next-gen here - so targeting a 7MHz 68000 is not necessary. But the performance problems on low end processors show, that there is room for improvement.

If you think that there is more wrong with AROS, what is it?

Originally Posted by Thorham

It's more about knowing the concepts involved then about implementing everything in the book as is.

For me, Amiga like wouldn't be the goal of writing a new OS anyway. We already have AOS, AOS 4, AROS and MorphOs. Seems more interesting to try something new.

As long as it is SAS, exokernel/library-centric, with fast (non blocking) message passing, it can be as different as you want

[Gorf]

Originally Posted by Megol

I wonder what construct would need 4-5 instructions when the 68k only need one? MOVEM possibly. However I can see many common operations where a 68k would need two+ instructions that map to one C/RISC instruction.

Can you give me some examples of code that take two or more instructions on 68k, but are just one instruction on RISC?

[Thorham]

Originally Posted by Gorf

As long as it is SAS

What's SAS? I tried googling it but that didn't get me very far.

[Gorf]

Originally Posted by Dunny

Having 64bit instructions makes my job much easier - audio processing. 64 bit floats are handled atomically for starters and having extra RAM immediately addressable is a godsend for working with multi-gigabyte instruments.

While I am not against more than 2 or 4 GB and can see the benefit of a larger address-space for some (rare) applications, your example does not convince me.

I still do not understand why one would hold multi-gigabytes of instrument-samples in RAM - especially in a highly redundant resolution.
you mentioned some latency related reasons, but that makes still no sense to me at all, since we are in the digital realm:
a higher sampling rate means just more data that needs to be processed. More data representing the same period of time. That means higher demand of RAM, bandwidths and processing power. How can this possibly reduce latency?

[Gorf]

Originally Posted by Thorham

What's SAS? I tried googling it but that didn't get me very far.

Single Address Space

https://en.wikipedia.org/wiki/Single...erating_system

(with a long list of such systems - also modern ones)