23 October 2018, 15:01 | #561 | ||||
Registered User
Join Date: Sep 2007
Location: Stockholm
Posts: 4,338
|
Quote:
Quote:
2. The VAX was not a big factor in the 68000 design — it was one example of a design onto which most CPUs converged. In comparison, the x86 wanted to share the success of the 8080 of the 70s, a design which belonged in the 70s. Quote:
The IBM/370 is a different beast altogether, and I begin to question your insight into CPUs when you repeatedly try to bunch it together with the VAX or 68000. Quote:
Really, from a CPU design perspective, what makes you think that the x86 with its non-orthogonal design, modes-upon-modes of compatibility layers and jungle of instructions is more scalable than the 68000? |
||||
27 October 2018, 13:33 | #562 |
Registered User
Join Date: Aug 2014
Location: Zagreb / Croatia
Posts: 302
|
|
27 October 2018, 15:16 | #563 | |
Registered User
Join Date: Dec 2017
Location: france
Posts: 186
|
Quote:
If the ARM is not fast, what about the 68k then ?? The 68k is slow, it has a really good ISA for sure, but it's slow . A 8mhz ARM2 can deliver 4 MIPS, i'll don't call this, not fast . |
|
27 October 2018, 15:53 | #564 | |
Banned
Join Date: Sep 2016
Location: UK
Posts: 2,917
|
Quote:
Yup. The 68K is much slower. The ARM has appalling code density but it’s much much faster. No microcode, fast interrupts, 3 stage pipeline, barrel shifter on every ALU instruction for free. Not sure who thinks this is slow? |
|
27 October 2018, 17:42 | #565 | |
Registered User
Join Date: Dec 2014
Location: germany
Posts: 439
|
Quote:
Oh, and at least early ARM CPUs do use some microcode, even if it is quite minimal: http://www.righto.com/2016/02/revers...rocessors.html Last edited by chb; 27 October 2018 at 17:50. |
|
27 October 2018, 19:37 | #566 |
Banned
Join Date: Sep 2016
Location: UK
Posts: 2,917
|
68k details
Ok. So are what are we comparing here? 030 isn’t as nicely pipelined, there isn’t a barrel shifter on every instruction. It’s got more complex addressing modes and horrible interrupt latency compared to ARM. ARMv2 does 1 instruction per clock when optimised properly... 030 doesn’t come close to that.
So what if the ARMv1 was microcoded. It was never released!! ARMv2 was the first production chip.. except for a handful of BBC B evaluation coprocessor boxes. Sure the 030s could reach 25MHz (vs 8MHz) but that’s mostly due to the manufacturing processes used .. VLSI vs Motorola rather than chip design. |
27 October 2018, 19:42 | #567 | ||||
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
@Kalms Thank you very much for your story. I think I have almost the same point.
@Bruce Abbott Thank you very much for your information. Some details of it are new for me. BTW Amiga 1000 with HDD, indeed, was a fantastic machine in the 80s. What a stupidity was made Commodore to miss its chance to spread this computers more! I agree CPC Basic was very fast but Mallard Basic for PCW was even much faster! I am impressed by your z80 experience I also have some - http://litwr2.atspace.eu/xlife/retro/xlife8.html - I hope to find enough spare time to write an Amiga version too. IMHO to program z80 is much more difficult than 8086 or even 6502. I do not understand your idea about Apple ][ to IBM PC transition. IMHO Apple ][ user went for Macintosh. IBM PC users were more natural from CP/M or TRS-80 users. IMHO the flexibility and power of the IBM PC architecture allow it be actual for more about 40 years! @meynaf 236 bytes - it is quite a result! I need time to work with it. Quote:
Quote:
I agree they share some details but it is rather not intentionally. RISC ppl wanted the fastest CPU while 68k tried to reach several goals simultaneously. Intel in this sense is close to ARM because they wanted just to get the winner. Quote:
Quote:
BTW. I wrote a drawline routine (http://eab.abime.net/showpost.php?p=...&postcount=463) for ARM processors. It takes 100 bytes for it (68000 - 72 bytes, 8086 - 84 bytes). Code:
; r0/r1 - x0/y0, r2 - c, r3/r4 - dx/dy, r5/r6 - x1/y1, r7 - err, r8 - e2, r9/r10 - sx/sy drawline: STMFD r13!,{R0-R10,R14} add r5,r0,r3 ;x1 = dx + x0 add r6,r1,r4 ;y1 = dy + y0 adds r3,r3,0 ;dx > 0 mvnmi r9,-1 ;sx = -1 movpl r9,1 ;sx = 1 rsbmi r3,r3,0 ;dx = abs(dx) adds r4,r4,0 ;dy > 0 movmi r10,-1 ;sy = -1 movpl r10,1 ;sy = 1 rsbpl r4,r4,0 ;dy = -abs(dy) add r7,r3,r4 ;err = dx + dy loop: bl putpixel cmp r5,r0 ;x0 == x1 cmpeq r6,r1 ;y0 == y1 LDMFDEQ r13!,{R0-R10,R15} ;break add r8,r7,r7 ;e2 = 2 * err cmp r8,r4 ;e2 >= dy addge r7,r7,r4 ;err += dy addge r0,r0,r9 ;x0 += sx cmp r8,r3 ;e2 <= dx addle r7,r7,r3 ;err += dy addle r1,r1,r10 ;y0 += sy b loop EDIT. The size of the code for ARM is 96 bytes now. Indeed it is larger than for 80386 or 68020 but it contains less instructions. Last edited by litwr; 27 October 2018 at 23:15. |
||||
27 October 2018, 19:48 | #568 |
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
@menaf I remember your difficulty about disassembly of x86 code. I have just found a help tool for you - http://shell-storm.org/online/Online...-Disassembler/ It's sad that it has missed 68k.
|
27 October 2018, 20:14 | #569 | |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,323
|
Quote:
This one does, however : https://onlinedisassembler.com/odaweb/ But regardless of which disassembler i try, there are always some ambiguous opcodes or some unsupported extensions. |
|
27 October 2018, 21:40 | #570 | |||
Registered User
Join Date: Dec 2014
Location: germany
Posts: 439
|
Well, my point was that in terms of absolute performance (not per clock) ARM CPUs were never among the fastest of their time. I guess that wasn't their goal anyway.
Quote:
Quote:
To quote wikichip: Quote:
No, it's because DRAM speed could not cope with an 25 MHz ARM2 without cache - or performance per clock would be drastically degraded. It's also a different design philosophy, bit like Z80 and 6502. |
|||
27 October 2018, 22:44 | #571 | |
Banned
Join Date: Sep 2016
Location: UK
Posts: 2,917
|
Quote:
The DRAM point is correct. Fixed in ARMv3. Compare an ARMv3 with an 030. |
|
28 October 2018, 02:53 | #572 |
Registered User
Join Date: Sep 2007
Location: Stockholm
Posts: 4,338
|
I never mentioned the 68000, did I. Please compare the ARM of any generation to other contemporaneous RISC processors, not to the 68000.
|
28 October 2018, 09:59 | #573 | |
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
Quote:
With the help of ARM experts I have just improved my codes for the ARM's line drawing routine. Code:
drawline: stmfd r13!,{r0-r10,r14} add r5,r0,r3 ;x1 = dx + x0 add r6,r1,r4 ;y1 = dy + y0 movs r9,r3,asr 31 ;dx > 0, sx = -1 movpl r9,1 ;sx = 1 rsbmi r3,r3,0 ;dx = abs(dx) movs r10,r4,asr 31 ;dy > 0, sy = -1 movpl r10,1 ;sy = 1 rsbpl r4,r4,0 ;dy = -abs(dy) add r7,r3,r4 ;err = dx + dy loop: bl putpixel cmp r5,r0 ;x0 == x1 cmpeq r6,r1 ;y0 == y1 ldmfdeq r13!,{r0-r10,r15} ;break add r8,r7,r7 ;e2 = 2*err cmp r8,r4 ;e2 >= dy addge r7,r7,r4 ;err += dy addge r0,r0,r9 ;x0 += sx cmp r8,r3 ;e2 <= dx addle r7,r7,r3 ;err += dy addle r1,r1,r10 ;y0 += sy b loop |
|
28 October 2018, 10:22 | #574 |
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
I have checked the 386 code and without timer support it can be less than 180 bytes. BTW I have published the code for 80286 by a mistake, the fair code for 386 is less than 386 bytes.
Last edited by litwr; 28 October 2018 at 11:15. |
28 October 2018, 10:34 | #575 | |
Banned
Join Date: Sep 2016
Location: UK
Posts: 2,917
|
Quote:
On any given day (certainly once we were into the 90s) the Intel chips always kicked everything else's butt because as @grond pointed out they had better fabrication labs and could put more transistors on there. It wasnt until the StrongARM that someone put good fab techniques into the ARM CPU. And boy did that make a difference. Again always comparing apples and oranges. Are we comparing chips on a given day? iterations of an ISA? the ISA potential? or the ability of a manufacturer to access the best fab techniques? Pick one. Otherwise its all rhetoric. However intel suffered from the same thing as the english language... because its so widely used it is the worst language with the longest history, most development and largest technical debt. Thats unavoidable in any industry where you are successful because nobody wants to change a winning formula.. even if its got piles of crap in there. Last edited by plasmab; 28 October 2018 at 10:57. |
|
28 October 2018, 11:15 | #576 |
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
@plasmab English is very tough. IMHO nobody knows it perfectly even the native speakers!
With help I have made other improvements to ARM code - it is only 80 bytes now - it is less than the code for 80386 and close to size size of 68000 codes (72 bytes)! Code:
drawline: stmfd r13!,{r0-r9,r14} add r5,r0,r3 ;x1 = dx + x0 add r6,r1,r4 ;y1 = dy + y0 movs r9,r3,asr 31 ;dx > 0, sx = -1 movpl r9,1 ;sx = 1 rsbmi r3,r3,0 ;dx = abs(dx) movs r8,r4,asr 31 ;dy > 0, sy = -1 movpl r8,1 ;sy = 1 rsbpl r4,r4,0 ;dy = -abs(dy) add r7,r3,r4 ;err = dx + dy loop: bl putpixel cmp r5,r0 ;x0 == x1 cmpeq r6,r1 ;y0 == y1 ldmfdeq r13!,{r0-r9,r15} ;break cmp r4,r7,lsl 1 ;err*2 >= dy addlt r7,r7,r4 ;err += dy addlt r0,r0,r9 ;x0 += sx cmp r3,r7,lsl 1 ;err*2 <= dx addgt r7,r7,r3 ;err += dy addgt r1,r1,r8 ;y0 += sy b loop Last edited by litwr; 28 October 2018 at 11:31. |
28 October 2018, 12:56 | #577 | |
Banned
Join Date: Sep 2016
Location: UK
Posts: 2,917
|
Quote:
I'd be interested to see that implemented in thumb mode. |
|
28 October 2018, 16:15 | #578 | |
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
Quote:
@plasmab Indeed, it is 84, the same as the code for x86. EDIT. The 80 bytes are real - https://stardot.org.uk/forums/viewto...=15941#p218910 Last edited by litwr; 28 October 2018 at 16:44. |
|
28 October 2018, 16:48 | #579 | |
Banned
Join Date: Sep 2016
Location: UK
Posts: 2,917
|
Quote:
The A310 was released in 1987, was 8Mhz and was also under £1000. |
|
28 October 2018, 17:53 | #580 | |
Registered User
Join Date: Jun 2015
Location: Germany
Posts: 1,918
|
Quote:
Well, ldm, stm, mul and divs all do well with microcode. Not much but not nothing either. Thanks God or rather Sophie Wilson that they did use microcode and not insist on the programmer using a bunch of primitive instructions to implement these instructions in macrocode... I think MIPS and also the earlier SPARC required the programmer to use a sequence of shift-add/subtract instructions in order to make multiplications and divisions. Last edited by grond; 28 October 2018 at 17:58. |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Any software to see technical OS details? | necronom | support.Other | 3 | 02 April 2016 12:05 |
2-star rarity details? | stet | HOL suggestions and feedback | 0 | 14 December 2015 05:24 |
EAB's FTP details... | Basquemactee1 | project.Amiga File Server | 2 | 30 October 2013 22:54 |
req details for sdl | turrican3 | request.Other | 0 | 20 April 2008 22:06 |
Forum Details | BippyM | request.Other | 0 | 15 May 2006 00:56 |
|
|