I am seeking a way to Amiga 1200...

[idrougge]

Moving zero page into registers sounds like a good idea, and possibly the only way around the fact that memory didn't gain speed as quickly as CPUs.

[meynaf]

Originally Posted by litwr

65C02 is a shame. 65816 is only slightly better and too late. MOS Techonology was crashed, its key figure (Chuck Peddle) became of CPU development. There was unfinished Synertek 6516 project - https://plus.google.com/108984290462...ts/6JeiVQrwKHi...

There are reasons why 6502 disappeared. 65C02 is just minor revision, 65816 is 16-bit extension and is already dirty. 32-bit extension would be even more dirty.

Originally Posted by litwr

I have some ideas how to extend 6502. Just move zero page to CPU memory. This gives 256 z80 style registers.

Just do it !
(And see why this would be a major pain at context switches.)

Originally Posted by litwr

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.

Everythings looks easy when you don't actually have to do it.

Some time ago i made some tests and saw why it can't work.
Roughly, if you have 100 free opcodes and 100 existing opcodes using the accumulator, just adding another accumulator will eat all of your encoding space.

Originally Posted by litwr

If you want, for example, to copy string you have to set the source and destination addresses and the string length. Intel's ISA has also to set the direction, it is one byte only very fast instruction.

But you set ONE direction. Can't use both anytime.

Originally Posted by litwr

It is close to a kind of a craziness for me. Are fine sources with macros, conditional assembly, etc the same as a raw dissasembly?!

I have resourced enough programs to tell you that it's not very different.
You can have macros, conditional assembly, comments, and that doesn't make it a different world.
But perhaps on x86 it does, as Intel's syntax is so awful ?

Originally Posted by litwr

Moto's ISA has always to support ambiguous second stack, the second stack pointer, ... x86 always uses one hardware stack, one stack pointer.

Once again : supervisor stack isn't ambiguous in any manner, and support costs next to nothing.
And x86 in protected more DOES switch the task in some way or another. Else it simply wouldn't work !

[meynaf]

Originally Posted by idrougge

Moving zero page into registers sounds like a good idea, and possibly the only way around the fact that memory didn't gain speed as quickly as CPUs.

Yeah, so you take 2 instructions to simply transfer R8 to R9 for example.
Adding them, even worse : LDA R8, CLC, ADC R9, STA R8.
Congratulations, you've made the slowest cpu in the world.

[kovacm]

Originally Posted by meynaf

Again comparing what should not. WB is slow because it is not asm code (and not especially well written anyway). Atari ST's desktop is already quite faster.

Neither Atari TOS is assembler code but there is one other thing: on Atari ST you can see and feel very good difference between C and Asm.!
Fot ST there are few software accelerators that speed up graphics replacing original TOS routs with Asm optimized one. Speed difference is astonishing! In average, operation are 4 times faster.

btw
very good thread! Thanks!

[Thorham]

Originally Posted by litwr

Moto's ISA has always to support ambiguous second stack, the second stack pointer, ... x86 always uses one hardware stack, one stack pointer.

It couldn't be less ambiguous if you tried. You're in user mode, a7 is the user stack. You're in supervisor mode, a7 is the supervisor stack. It couldn't be simpler

Originally Posted by meynaf

Some time ago i made some tests and saw why it can't work. Roughly, if you have 100 free opcodes and 100 existing opcodes using the accumulator, just adding another accumulator will eat all of your encoding space.

Variable length encoding

[litwr]

Originally Posted by meynaf

Yeah, so you take 2 instructions to simply transfer R8 to R9 for example.
Adding them, even worse : LDA R8, CLC, ADC R9, STA R8.
Congratulations, you've made the slowest cpu in the world.

Yes, transfer will cost two instructions but every instruction will take 1 clock only. It will be super speed even at the end of 80s. Then they might add more pipelines, etc...
Addition doesn't require CLC for every ADC. R8 and R9 maybe 32 bit. So we have 3 clocks, not bad too. We have access to every byte, which is difficult with 680x0 or even x86. I don't see a problem with opcode space, we may use 16-bit opcodes for 16/32-bit operations. For example, 6309 has 4 accumulators and 16-bit instructions and it works fine.

I have resourced enough programs to tell you that it's not very different.

It is sad that sometimes we have to deal with fanaticism which claims just slogans. You may even say that Prolog, Haskell or C++ program sources and its debugger disassemmbly are the same.

[meynaf]

Originally Posted by Thorham

Variable length encoding

Yeah, and it wouldn't be simple and easy 6502 anymore. More like 65816 maybe, and we know where it ended.
It would work, ok. But there would be no advantage in comparison to other cpu families.

Originally Posted by litwr

Yes, transfer will cost two instructions but every instruction will take 1 clock only.

That's enough to make it slow.

Originally Posted by litwr

It will be super speed even at the end of 80s. Then they might add more pipelines, etc...

We're no longer at the end of 80s.

Originally Posted by litwr

Addition doesn't require CLC for every ADC. R8 and R9 maybe 32 bit. So we have 3 clocks, not bad too. We have access to every byte, which is difficult with 680x0 or even x86. I don't see a problem with opcode space, we may use 16-bit opcodes for 16/32-bit operations.

3 clocks to perform an add, where modern cpu can do several adds per clock...

Originally Posted by litwr

For example, 6309 has 4 accumulators and 16-bit instructions and it works fine.

And is dead.

Originally Posted by litwr

It is sad that sometimes we have to deal with fanaticism which claims just slogans. You may even say that Prolog, Haskell or C++ program sources and its debugger disassemmbly are the same.

It's not a slogan, it is reality. Fanaticism is on your side, not mine
It's you who claim just slogans.
It's not my fault if x86 debuggers are very poor and very stupid.

I suggest you try software such as ReSource, IRA or ADis.
Then perhaps you would stop writing nonsense.
Output of a disassembler can directly be used as source.
So they are basically the same.

[litwr]

I would like to see a disassembler which restores proper labels, names and comments. I am very disappointed.
I showed you the possibility to expand 6502 which allowed it to be the speed champion to the end of 80s. More parallelism together with easy ISA might prolong it to the middle of the 90s. Then they might change ISA and use legacy mode for the compatibility.
The main advantage of 6502 architecture is in absence of contrived theoretical complexity which slows program execution. 680x0 has a lot such complexity, x86 has lesser.

[meynaf]

Originally Posted by litwr

I would like to see a disassembler which restores proper labels, names and comments. I am very disappointed.

Can't you read ?
I explicitly wrote You can have macros, conditional assembly, comments, and that doesn't make it a different world.

Originally Posted by litwr

I showed you the possibility to expand 6502 which allowed it to be the speed champion to the end of 80s. More parallelism together with easy ISA might prolong it to the middle of the 90s.

We're not in the middle of the 90s anymore.

Originally Posted by litwr

Then they might change ISA and use legacy mode for the compatibility.

Already done. Gave useless 65816.
A bigger ISA change would turn it into something that's not 6502 anymore but bloated cpu with integrated 6502 emulation.

Originally Posted by litwr

The main advantage of 6502 architecture is in absence of contrived theoretical complexity which slows program execution.

You can't keep that and go to 32 bit.

Originally Posted by litwr

680x0 has a lot such complexity, x86 has lesser.

This is just plain 100% wrong. x86 is so uselessly complex it's hard to believe.
Today 68k can be made in fpga. Current x86 can't, too complicated.

[matthey]

Originally Posted by litwr

I would like to see a disassembler which restores proper labels, names and comments.

ADis will use symbols (labels and names) if the executable contains them. They even help improve the accuracy of the disassembled output.

http://eab.abime.net/showthread.php?...highlight=ADis

Try it on an executable with symbols. Over half of AmigaOS friendly executables can be disassembled and reassembled with vasm with no problems. Vasm's excellent peephole optimizer can be enabled to improve the performance and size of most executables also. I spent a lot of time fixing up the old ADis source to get it working this well. There are no modes or ambiguities to worry about with the 68k but small amounts of data are sometimes difficult to tell from code (probably true with most ISAs).

[litwr]

BTW the guys from Amibay could really help - http://www.amibay.com/showthread.php...run-it-for-me! So the real iron is about 10% slower than FS-UAE and this makes i80386 @12.5MHz faster - http://litwr2.atspace.eu/pi/pi-spigot-benchmark.html
[6502] http://forum.6502.org/viewtopic.php?f=4&t=4524
@matthey Your next step will be "the proof" that 680x0 disassembler could restore C++ sources from compiled, optimized and stripped code. Bravo! It looks also that you are an unconditional x86 ISA admirer. I am too but conditional.

[BippyM]

This is another thread that has deteriorated into the PC being better than amiga, x86 being better than 680x0..

Closed