23 May 2018, 17:43 | #521 | |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 47
Posts: 3,810
|
Quote:
No, you don't, but you can still use the script language for automating things if you want. Just what's in the archive I gave you earlier. You didn't try just double clicking the icon? Seems more time consuming than hard, actually. |
|
23 May 2018, 18:04 | #522 | |||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,350
|
Nope this is the opposite of what I wrote
Quote:
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:
Quote:
I guess it's a nice mixture of both... |
|||
23 May 2018, 18:34 | #523 |
Registered User
Join Date: May 2017
Location: Munich/Bavaria
Posts: 2,414
|
|
23 May 2018, 19:18 | #524 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,350
|
|
23 May 2018, 20:24 | #525 | |||||
Registered User
Join Date: May 2014
Location: inside the emulator
Posts: 377
|
Quote:
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:
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:
Quote:
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:
|
|||||
23 May 2018, 21:21 | #526 | |||||||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,350
|
A few percent, for about everything being twice the size ?
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:
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:
And anyway the case is too rare to account for anything significant. Quote:
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:
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". 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. Nope. If you see a problem, explain it. Quote:
Second, no popular processor architecture is really there anymore. Quote:
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:
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. |
|||||||
24 May 2018, 00:07 | #527 |
Registered User
Join Date: Aug 2006
Location: Scunthorpe/United Kingdom
Posts: 2,053
|
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.
|
24 May 2018, 01:16 | #528 | |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 47
Posts: 3,810
|
Still doesn't seem too difficult, especially since I have an OS book. Quote:
For writing in assembly language, probably. |
|
24 May 2018, 07:42 | #529 |
Registered User
Join Date: Feb 2008
Location: RNO
Posts: 1,007
|
|
24 May 2018, 09:58 | #530 | |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,350
|
Quote:
Besides, you're probably not coding your audio processing software in asm so it is not relevant. |
|
24 May 2018, 10:01 | #531 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,350
|
|
24 May 2018, 10:39 | #532 | ||
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 47
Posts: 3,810
|
Quote:
Indeed. Even old 16bit FPUs can handle 64bit (and 80bit!) floats. Quote:
It's the book Operating System Concepts. |
||
24 May 2018, 11:03 | #533 |
Registered User
Join Date: May 2017
Location: Munich/Bavaria
Posts: 2,414
|
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. |
24 May 2018, 11:18 | #534 |
Registered User
Join Date: Aug 2006
Location: Scunthorpe/United Kingdom
Posts: 2,053
|
|
24 May 2018, 11:26 | #535 | |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 47
Posts: 3,810
|
Quote:
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. |
|
24 May 2018, 12:09 | #536 | ||
Registered User
Join Date: May 2017
Location: Munich/Bavaria
Posts: 2,414
|
Quote:
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? As long as it is SAS, exokernel/library-centric, with fast (non blocking) message passing, it can be as different as you want |
||
24 May 2018, 12:16 | #537 |
Registered User
Join Date: May 2017
Location: Munich/Bavaria
Posts: 2,414
|
Can you give me some examples of code that take two or more instructions on 68k, but are just one instruction on RISC?
|
24 May 2018, 12:18 | #538 |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 47
Posts: 3,810
|
|
24 May 2018, 12:51 | #539 | |
Registered User
Join Date: May 2017
Location: Munich/Bavaria
Posts: 2,414
|
Quote:
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. |
|
24 May 2018, 12:53 | #540 | |
Registered User
Join Date: May 2017
Location: Munich/Bavaria
Posts: 2,414
|
Quote:
https://en.wikipedia.org/wiki/Single...erating_system (with a long list of such systems - also modern ones) |
|
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 |
|
|