03 February 2017, 18:19 | #21 | |||||||||
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
Quote:
Quote:
Quote:
x86 in protected mode uses gates. Trap and interrupt gates use common stack, task gates are a bit complicated but they are absolutely safe. Quote:
Quote:
MOV EAX,[ESP+120] ;8B 44 24 78 MOV EAX,[EBP] ;8B 45 00 Quote:
Quote:
Quote:
JS label_1 ;bit 7 is set JPO label_2 ;bit 5 is set label_1 JPE label_3 ;bit 5 is set ... BTST (like BT at x86) can work with one bit only. Quote:
Pi-spigot is based mostly on division. Division occupies more than 60% of execution time. However ARM1 without hardware division faster 68020. So it is evident that ARM with the code without BCD and division is about 50% faster than 68020. Last edited by litwr; 03 February 2017 at 18:44. |
|||||||||
03 February 2017, 18:32 | #22 | ||
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
Quote:
Quote:
|
||
03 February 2017, 20:09 | #23 | |||||||||||||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,323
|
Quote:
On some 68k (like 68020) it's faster than ASL - because it does not have to compute V bit. Quote:
Note that it's not the only case when two operations are exactly the same thing. Not with dual issue pipelines. Prefixes are also more difficult to decode. And DBcc is also more versatile, can do things such as DBCS (with carry), which x86 prefixes can't. Except that sometimes you will forget to set DF correctly and get random bugs depending on where the code is called from... Quote:
Quote:
And compilers are very poor at this task anyway (always have, always will). Quote:
No. What experience ? No. If a user program has full stack (so pushing something more will trigger protection fault) and then an interrupt comes, what happens with single stack ? Crash in supervisor mode ! Even better. With an MMU in paged mode, it simply can't work anymore. There you *NEED* a new stack pointer as the old one goes in memory that's remapped user land. Even x86 appears to be changing stack for this. At least 68k has consistent behavior in protected and not protected environments. Quote:
Quote:
DOS doesn't multitask. It took Windows decades to be stable enough for normal use. Quote:
Quote:
You can't do byte operations on ESI, EDI, you can't use increment/decrement address mode on EAX, etc. The list is very long. Don't you remember your last BSOD ? Quote:
Quote:
We can test 4 bits with MOVE D0,CCR + BNE/BCS/BVS/BMI. That's what i told you, address registers are also useful for computations. Of course as it does not have address registers. ... which is a totally useless operation. But ARM can't do : add.w d0,(a0)+ ... which is a lot more useful. Or even : eori.l $80808080,(a1)+ In fact ARM can't really work with 16-bit words. It has to use extra instructions for load/store (can't operate in memory). Can't access misaligned data. Etc. Quote:
No it does not. You have to use an extra instruction (SED) before. 68k does BCD directly. Quote:
It has way too few registers. It doesn't even have proper ADD and SUB instructions (must CLC/SEC before). Etc. So no, other components aren't "almost perfect". 6502 has very few transistors and remarkable instruction timings. And that's all for its qualities. Would you post code if I start a new thread ? If not, why should I, as you're alone here defending the undefendable ? For spigot 9-instruction main loop it's like this : Code:
.loop mulu.l d0,d5 move.w (a3),d6 mulu.w d3,d6 add.l d6,d5 divul.l d4,d6:d5 move.w d6,(a3)+ subq.l #2,d4 subq.w #1,d0 bne .loop Last edited by meynaf; 03 February 2017 at 20:17. |
|||||||||||||
04 February 2017, 19:18 | #24 | ||||||||||||||||||||||
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
I want to clarify my position. I like Amigas. A500 sound made me a happy man at the 1989-90. I was sure that 68000 with 32-bit registers is much better than even 80286. However my first attempts to write programs in 68000 assembler showed that 68000 registers are a bit slow and all its ISA is a bit clunky. With 80286 @12Mhz I could get lesser and much faster code than the code for 68000 @7.1MHz. So I had to sell my A500 and bought PC AT. A1200 at 1992 was good but PC 386DX @25MHz with HDD, SuperVGA and Sound Blaster 16 showed much better choice for me at 1993. So I missed 68020 programming. I can note today that 68020 is quite capable to match 80386 but at the same frequency only. Motorola added as usual some bulky instructions to 68020...
68030, 68040, 68060 are just names for me. IMHO Motorola might evade unnecessary complexity and gain more frequency and speed. But they were wrong since they rejected the speed champion 6502. I forget to note yet another Moto's oddity. It is DBRA which stops at the value -1. I can write MOV CX,5 L ... LOOP L and get a loop for 5 times, I should write MOV 4,R0 L ... DBRA R0,L for 5 time loop. Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
I have to add some information about stack. A lot of modern x86 program may use unlimited stack technology. This allows, for example, the unlimited recursion. All this usefulness is based on one hardware stack. Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Code:
sub.l d6,d5 sub.l d7,d5 lsr.l d5 Last edited by litwr; 04 February 2017 at 23:47. |
||||||||||||||||||||||
04 February 2017, 20:20 | #25 |
Registered User
Join Date: Sep 2007
Location: Stockholm
Posts: 4,338
|
The fact that x86 code is compact should not be disputed, but if I were writing a compiler, I would stay very far away from that architecture, especially in its incarnations that were concurrent with the 68k line — guess why virtually no-one outside of IBM ever used Intel processors for new architectures. Yes, there is a distinction between address and data registers, but otherwise the 68000 was the most orthogonal design of its time. Just like if you compare the 6502 to the Intel/Z80 CPUs.
|
05 February 2017, 01:40 | #26 | |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 47
Posts: 3,768
|
You sold your Amiga500 for a 286 peecee? Really? Horrible
Quote:
That's a human oddity. Humans start counting at 1 instead of 0. It's what we're used to. This is similar to arrays starting at 0 instead of 1. |
|
05 February 2017, 09:58 | #27 | |||||||||||||||||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,323
|
Look at the horrors that got added to x86. More than 1,000 instructions in total. And you dare to say 68020 is bulky !
Quote:
Quote:
Code:
bra .next .for ; do something here .next dbra d0,.for That said, it's true i'd really like to have both options. Quote:
Quote:
Quote:
Anyway i can fire a disassembler and get this in seconds : Code:
eori.b #$30,d5 move.b d5,(a0)+ rts Quote:
On 68k I beat GCC by a factor of 4. Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Sure but they're quite a lot better than just having 8 regs. On 68020 too. Quote:
Quote:
68060 doesn't heat too much either. ARM is fully pipelined. Not 68020. You're comparing apples and oranges. 68060 @8Mhz would outperform ARM @20Mhz. Quote:
Quote:
And again 6502 is limited to 8 bits so it can't be a speed champion anymore. As you can NOT expand it to 32-bit without turning it into an horror (and as said before 65c816 is already not nice). Quote:
Now prepare your code samples I didn't say it was fast. I just said 9 instructions. |
|||||||||||||||||
05 February 2017, 12:53 | #28 | |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 47
Posts: 3,768
|
Quote:
|
|
05 February 2017, 13:03 | #29 | |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,323
|
Quote:
|
|
05 February 2017, 13:11 | #30 | |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 47
Posts: 3,768
|
Quote:
|
|
05 February 2017, 13:16 | #31 | |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,323
|
Quote:
|
|
05 February 2017, 13:20 | #32 |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 47
Posts: 3,768
|
|
05 February 2017, 13:38 | #33 | ||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,323
|
Quote:
Note that x86 also has a few undoc opcodes, and some opcode conflicts as well (like Cyrix SIMD extensions that are now defunct, or some instructions implemented in 386/486 but not documented that you later find under another opcode, etc). Quote:
Now from that doc, tell me the opcodes for : - instructions in Bit manipulations (BMI1 and BMI2) extensions - instructions in Transactional extensions (TSX) Yeah, there is always something missing. And who knows what else simply isn't there. |
||
05 February 2017, 15:49 | #34 | |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 47
Posts: 3,768
|
Quote:
Won't the official docs do? |
|
05 February 2017, 16:06 | #35 | |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,323
|
Quote:
Perhaps, provided it's possible to find one which is up to date. |
|
06 February 2017, 18:05 | #36 |
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
I have to expess my gratitude for this so interesting discussion. A500 was very good but a bit slow and poorly expandable. I still want to reach a genuine A1200.
@Thorham I used my first PC to play Wolfenstein 3D, Civilization and the best Ultima VI at 1991. Dune 2 was very good at 1992. Ultima VII was the excellent for this year too. Commodore always missed the idea of upgrade. They could make 4 MHz C64 at 1985, Amiga with 68020 at 1989, ... IMHO Commodore killed every thing which it touched to: 6502, VIC-2, C64, SFD-1001, C+4, Amiga, ... @meynaf I agree that 65816 is a bit wrong chip. IMHO it was a kind of the great struggle against the terminator 6502 which might terminate both Intel and Motorola. So after MOS Technology lost the battle 6502 development was left almost completely. The winners even constructed a joke about 6502 JMP () bug and made an "improved" 65C02. IMHO 6502 might be extended to 32 bits. It has a lot of free opcodes. They might add more accumulators, etc. 65816 lost the main feature of 6502 the speed. 4510 was much better but might be made in the 70s. Try to compare the upgraded 6809 6309 and 65816. 6308 has power of 2 or 3 6809 but the speed of 65816 for 16 bit code is only 50% faster than 6502 and the same or even slower for 8-bit. 6502 was the champion to the end of the 70s. It is faster than 68000 at the same frequency. Intel's LOOP instruction may start a loop with CX=0 that means 65536 times. No any advantage of DBRA was shown. Sorry, it was me who was not ok. I forgot that x86 ISA has several opcodes for the same instruction: ADD, SUB, ... SHL/SAL is among them. I have an excuse in the fact that almost all (all?) assemblers compile SAL and SHL into the same opcode. My other excuse is in the fact that Intel's 8086 manual gives one opcode too. I agree that Intel's documentation is always slightly incomplete. They don't like to write about bugs and missed instructions (like IBTS). They have a monopoly but they worked better than Motorola. I don't find a reason in claiming STD or CLD instructions useless. They are one byte only part of a setup for a string instruction. This setup includes also setting of one or two index registers and a counter register - it is the same as at 680x0. I have found a contradiction in your logic. You wrote about readability at source level. I gave you an example of x86_64 assembly and you wrote about the debugger level. They are not the same levels. It looks like that GCC for 680x0 has much more poor optimizer than for x86. It is almost impossible to beat GCC at x86 by the manual assembly. Thank you for the example for the second 680x0 stack. I missed that simple idea. However it means little because it is about protection only a few dozen of bytes of the system stack, all other memory maybe corrupted by a wrong program. So giving 0.1% safer system by the expensive 2nd stack concept is not very good idea. It can't solve the problem which maybe solved by memory protection only. It only makes architecture more complex and bulky. You wrote that the same x86 binary code can't work the same in three x86 modes. It is more than obvious. Indeed it creates problem to you in your debugger project... The code orthogonality is an obsolete concept from the 60s and 70s when programmer had to use assembler for almost every task. Motorola missed that the speed, timeliness and price mean much more. I want to have an opportunity to do something for 68060 but it is almost a legendary rarity. There are no systems with it. However I doubt that 68060 can outperform ARM much at the same frequency. AAM и AAD are very complex instructions but they are also archaic and useless. |
06 February 2017, 18:36 | #37 | |||||||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,323
|
Quote:
Get 8 accumulators and it's *8 encoding space. Add three sizes and it's *3 again. Have 16 registers instead of 8, again *2. Addressing modes can only handle byte and word address, so you'll probably need another more bit. No, sorry, 6502 can't be extended to 32 bits. If you still believe otherwise i'd be happy if you show me the instruction encoding that this would give (because it's really a matter of encoding, which is reasonably simple on 6502 so they could use a modest logic array for the decoder). Quote:
Besides, it uses double indirect modes for pointers and this is very bad for modern implementations. In addition it is too memory driven and is totally unable to run at high frequencies. Quote:
I am not for choosing, i would want an instruction for each case. Quote:
Quote:
Quote:
Quote:
Ok it does not solve what memory protection does, but at least, the programming model remains unchanged regardless if there is memory protection or not. x86 protection is big and cumbersome. Take it as a whole or leave it. 68k protection can be none, light (e.g. enforcer) or full (paged like in linux), or anywhere in between. You have the choice. When you code in user land you don't have "two stacks". You only have one. When you do some demo or game killing the OS you run in supervisor mode and USP is just a register that has no use in these circumstances so you can ignore it. |
|||||||
06 February 2017, 20:32 | #38 | |||||
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
Quote:
Quote:
Quote:
Quote:
Quote:
Last edited by litwr; 06 February 2017 at 20:42. |
|||||
06 February 2017, 21:21 | #39 | ||||||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,323
|
Quote:
Quote:
6502 upgrade was 65816 and nothing better can be done. 6502 is simple and if you "upgrade" it, it will cease to be simple. As easy as that. Quote:
Quote:
Code as seen in a source file is very near to that of a good disassembler output. Quote:
Quote:
My point is that protection shouldn't change anything apart some memory cells become unavailable. But, why the heck do you insist on "two stacks" ? There is only one stack at any given time !!! |
||||||
07 February 2017, 09:01 | #40 | ||||
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
Quote:
I have some ideas how to extend 6502. Just move zero page to CPU memory. This gives 256 z80 style registers. They maybe used as 128 16-bit registers or 64 32-bit. Add 3 8-bit accumulators, add 16- and 32-bit operations for the registers, provide a way to extend index registers, ... I know there is a project for 32-bit 6502, try to seek the net for it. Quote:
Quote:
Quote:
Last edited by litwr; 07 February 2017 at 15:59. |
||||
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
FOR SALE: Amiga 1200 Job Lot 200+ games, 2x Amiga 1200 lots of accessories and spares | erniet5 | MarketPlace | 0 | 28 April 2015 13:34 |
Desperately seeking Amiga Demo Coder | slayerGTN | Amiga scene | 2 | 02 August 2010 23:34 |
Seeking External Amiga Disk Drives (AMP) | Crown | MarketPlace | 5 | 29 October 2008 19:34 |
Seeking for 1 or 2 external disk drives (amiga) | Crown | MarketPlace | 0 | 08 September 2006 09:42 |
Seeking for Amiga music composers | Crown | Amiga scene | 0 | 18 May 2006 12:47 |
|
|