English Amiga Board


Go Back   English Amiga Board > Main > Amiga scene

 
 
Thread Tools
Old 23 May 2018, 17:43   #521
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 42
Posts: 3,084
Quote:
Originally Posted by meynaf View Post
That's not what i understood from what you wrote a few posts earlier
Somehow I didn't understand exactly what you meant

Quote:
Originally Posted by meynaf View Post
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.

Quote:
Originally Posted by meynaf View Post
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?

Quote:
Originally Posted by meynaf View Post
As hard as writing a new OS is, no more no less.
Seems more time consuming than hard, actually.
Thorham is offline  
Old 23 May 2018, 18:04   #522
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 45
Posts: 3,202
Quote:
Originally Posted by Gorf View Post
you are right: SIMD in (a new) instruction set are a must.
Nope this is the opposite of what I wrote


Quote:
Originally Posted by Gorf View Post
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.


Quote:
Originally Posted by Gorf View Post
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 ?



Quote:
Originally Posted by Thorham View Post
Just what's in the archive I gave you earlier. You didn't try just double clicking the icon?
There was an icon ?


Quote:
Originally Posted by Thorham View Post
Seems more time consuming than hard, actually.
I guess it's a nice mixture of both...
meynaf is offline  
Old 23 May 2018, 18:34   #523
Gorf
Registered User

 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 547
Quote:
Originally Posted by meynaf View Post
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?
Gorf is offline  
Old 23 May 2018, 19:18   #524
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 45
Posts: 3,202
Quote:
Originally Posted by Gorf View Post
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.
meynaf is offline  
Old 23 May 2018, 20:24   #525
Megol
Registered User

Megol's Avatar
 
Join Date: May 2014
Location: inside the emulator
Posts: 332
Quote:
Originally Posted by meynaf View Post
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.

Quote:
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.

Quote:
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.

Quote:
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.

Quote:
It would just be horrible to code on. Besides, it would have very poor code density.
Everything but 68k is apparently horrible.
Megol is offline  
Old 23 May 2018, 21:21   #526
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 45
Posts: 3,202
Quote:
Originally Posted by Megol View Post
Smaller: yes. A few percent at most.
A few percent, for about everything being twice the size ?


Quote:
Originally Posted by Megol View Post
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.


Quote:
Originally Posted by Megol View Post
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.


Quote:
Originally Posted by Megol View Post
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.


Quote:
Originally Posted by Megol View Post
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 !


Quote:
Originally Posted by Megol View Post
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.


Quote:
Originally Posted by Megol View Post
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.


Quote:
Originally Posted by Megol View Post
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".


Quote:
Originally Posted by Megol View Post
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.


Quote:
Originally Posted by Megol View Post
you want to complicate hardware making it slower
Nope.


Quote:
Originally Posted by Megol View Post
and you don't see the problem.
If you see a problem, explain it.


Quote:
Originally Posted by Megol View Post
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.


Quote:
Originally Posted by Megol View Post
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).


Quote:
Originally Posted by Megol View Post
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.


Quote:
Originally Posted by Megol View Post
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.
meynaf is offline  
Old 24 May 2018, 00:07   #527
Dunny
Registered User

Dunny's Avatar
 
Join Date: Aug 2006
Location: Scunthorpe/United Kingdom
Posts: 1,067
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.
Dunny is offline  
Old 24 May 2018, 01:16   #528
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 42
Posts: 3,084
Quote:
Originally Posted by meynaf View Post
There was an icon ?


Quote:
Originally Posted by meynaf View Post
I guess it's a nice mixture of both...
Still doesn't seem too difficult, especially since I have an OS book.

Quote:
Originally Posted by Gorf View Post
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.

Quote:
Originally Posted by Megol View Post
Everything but 68k is apparently horrible.
For writing in assembly language, probably.
Thorham is offline  
Old 24 May 2018, 07:42   #529
jPV
Registered User
jPV's Avatar
 
Join Date: Feb 2008
Location: RNO
Posts: 618
Quote:
Originally Posted by Thorham View Post
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
jPV is offline  
Old 24 May 2018, 09:58   #530
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 45
Posts: 3,202
Quote:
Originally Posted by Dunny View Post
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 is offline  
Old 24 May 2018, 10:01   #531
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 45
Posts: 3,202
Quote:
Originally Posted by Thorham View Post
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" ?
meynaf is offline  
Old 24 May 2018, 10:39   #532
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 42
Posts: 3,084
Quote:
Originally Posted by jPV View Post
Heh, ask MorphOS developers why they don't do code exchange with AROS anymore
Is it that bad?

Quote:
Originally Posted by meynaf View Post
64-bit floats are different to the normal instruction set.
Indeed. Even old 16bit FPUs can handle 64bit (and 80bit!) floats.

Quote:
Originally Posted by meynaf View Post
An OS book ? Is it "How to write an operating system in ten lessons" ?


It's the book Operating System Concepts.
Thorham is offline  
Old 24 May 2018, 11:03   #533
Gorf
Registered User

 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 547
Quote:
Originally Posted by Thorham View Post
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.
Gorf is offline  
Old 24 May 2018, 11:18   #534
Dunny
Registered User

Dunny's Avatar
 
Join Date: Aug 2006
Location: Scunthorpe/United Kingdom
Posts: 1,067
Quote:
Originally Posted by meynaf View Post
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
Dunny is offline  
Old 24 May 2018, 11:26   #535
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 42
Posts: 3,084
Quote:
Originally Posted by Gorf View Post
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.

Quote:
Originally Posted by Gorf View Post
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.
Thorham is offline  
Old 24 May 2018, 12:09   #536
Gorf
Registered User

 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 547
Quote:
Originally Posted by jPV View Post
Quote:
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
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?

Quote:
Originally Posted by Thorham View Post
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 is offline  
Old 24 May 2018, 12:16   #537
Gorf
Registered User

 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 547
Quote:
Originally Posted by Megol View Post
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?
Gorf is offline  
Old 24 May 2018, 12:18   #538
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 42
Posts: 3,084
Quote:
Originally Posted by Gorf View Post
As long as it is SAS
What's SAS? I tried googling it but that didn't get me very far.
Thorham is offline  
Old 24 May 2018, 12:51   #539
Gorf
Registered User

 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 547
Quote:
Originally Posted by Dunny View Post
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?

Last edited by Gorf; 24 May 2018 at 12:56.
Gorf is offline  
Old 24 May 2018, 12:53   #540
Gorf
Registered User

 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 547
Quote:
Originally Posted by Thorham View Post
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)
Gorf is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Has anyone got an Amiga 1200 T12 Gen II? ccorkin support.Hardware 10 14 April 2017 23:18
What do people think about this as next Gen AMIGA? Gunnar Amiga scene 111 05 July 2014 20:59
Classic 1st Gen EA games for the Amiga illy5603 support.Games 8 03 July 2010 02:59
Next-gen Amiga development LaundroMat Coders. General 3 05 October 2002 00:30

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 21:51.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.11539 seconds with 16 queries