6502 can be faster than 68k :-)

[yzoer]

Been a while since I've replied to this thread..

So I kinda have a dilemma I'm designing a new system and, as already as been pointed out here, what the 68k8 has going for it are:

Large contiguous memory (4MB on the PLCC version)
8-bit data-bus reduces components / pins
high-level language support (C/C++)
more registers, multiply, divide, etc.

What it's going against it though, is that accessing memory is slow as hell. Similar loops over 256 elements in a 2d array are about 5-6 times slower, based on 16-bit elements, compared to a 6502 (same memory speed for both). It's all nice and well to have the above mentioned features, but if you're severely hobbled by the fact that you can execute less instructions, it's kinda pointless.

I really, really want to like the 68k8 but I keep coming back to 6502!

(unbiased) Thoughts?

Yvo

[ElEctric_EyE]

yzoer wrote:

...(unbiased) Thoughts?

Yvo

Investigate FPGA CPU softcores.
Investigate current ARM CPUs.

[GARTHWILSON]

yzoer wrote:

Large contiguous memory (4MB on the PLCC version)

65816 addresses 16MB, and it's a natural extension of the 6502, if that's what you want.

Quote:

8-bit data-bus reduces components / pins

65816 allows you to put the registers into 16-bit mode, but the data bus is still 8-bit.

Quote:

high-level language support (C/C++)

http://www.westerndesigncenter.com/wdc/tools.cfm
http://www.westerndesigncenter.com/wdc/ ... /816cc.pdf

Quote:

more registers, multiply, divide, etc.

See http://wilsonminesco.com/16bitMathTables/index.html which is about using large look-up tables for hyperfast, accurate, 16-bit scaled-integer math, including multiplication, inversion (with 32-bit results), trig, & log functions, in many cases hundreds of times as fast as actually calculating the functions, yet the tables supplied are accurate to all 16 bits, with no interpolation necessary.

As far as the greater number of registers goes, that seems to be a bigger asset for compilers. BigEd observed, "With 6502, I suspect more than one beginner has wondered why they can't do arithmetic or logic operations on X or Y, or struggled to remember which addressing modes use which of the two. And then the intermediate 6502 programmer will be loading and saving X and Y, while the expert always seems to have the right values already in place." I think the 6502 (and '816) are easier to write assembly for. Although most assembly we see is attrocious, assembly does not require spaghetti code and preclude having program structures. See my article on implementing program structures in 65c02 assembly, through macros, yielding benefits of higher-level languages without robbing any of the efficiency or control of assembly.

[BigDumbDinosaur]

yzoer wrote:

Been a while since I've replied to this thread..

So I kinda have a dilemma I'm designing a new system and, as already as been pointed out here, what the 68k8 has going for it are:

Large contiguous memory (4MB on the PLCC version)
8-bit data-bus reduces components / pins
high-level language support (C/C++)
more registers, multiply, divide, etc.

What it's going against it though, is that accessing memory is slow as hell. Similar loops over 256 elements in a 2d array are about 5-6 times slower, based on 16-bit elements, compared to a 6502 (same memory speed for both). It's all nice and well to have the above mentioned features, but if you're severely hobbled by the fact that you can execute less instructions, it's kinda pointless.

I really, really want to like the 68k8 but I keep coming back to 6502!

(unbiased) Thoughts?

Yvo

Don't forget the 68K's horribly slow interrupt response.

[yzoer]

Thanks for the links, Garth!

The IDE license is actually quite reasonable at $40! Anyone have any experiences (good or bad) with it? I'll have a look at it tonight when I'm not at work and might buy it if it produces decent code.

As far as math goes, I've got enough space in my FPGA to do some hardware multiplication/division, so that's not really that much of an issue. While I also have no issue programming in assembler, most people probably more comfortable (not necessarily on this board) writing in C/C++ which is why I leaned more towards the 68k8.

Anyway, I'll check out the IDE and the code generation in the next couple of days and will share my findings..

Yvo

[GARTHWILSON]

yzoer wrote:

Thanks for the links, Garth! [...] As far as math goes, I've got enough space in my FPGA to do some hardware multiplication/division, so that's not really that much of an issue.

Multiplication can be done in a single cycle, but I think division is always a mess. Remember that it will take many multiplications and divisions to get certain functions, whereas with the tables, you can look them up directly, with no calculation; so the tables are still faster.

[yzoer]

Yeah, multiplies *can* be done in a single cycle but you'll end up spending quite a bit of logic on them. Even more so for divisions. I've opted for basically doing it the same way as you would on the CPU, bit-by-bit. While that sounds slow, mind you that a) it runs at one bit per clock and b) it's asynchronous so the CPU can do other things while it's calculating the result. For complicated functions, table lookups still rule though!

[BigEd]

Hi yzoer, in the Xilinx FPGAs I'm familiar with, there are more than enough 18x18 multipliers going spare - you don't use up much more logic in using them, as they are dedicated parts of the FPGA which are otherwise idle. (You need 4 for a straightforward 32x32 multiply)

However, division is indeed tricky, and I think a divide-step instruction in your CPU is a good approach.

Cheers
Ed

[yzoer]

Hi BigEd,

I'm using ancient Altera technology (EPF10k10 FPGA/EPM7128 CPLD) for reasons I still don't understand myself.

So neither of them have built-in hardware multipliers. That said, they come in PLCC, take 5V and are easy to prototype with. I've used Cyclones and other smt devices but they're just a pain to work with, especially when they've got 0.5mm pins and ground-pads. And don't get me started on those QFN packages

Anyway, given their limited resources, they're fun to work with!

[BigEd]

Ah, OK, that makes good sense! Even the SPARC had only a divide-step and a multiply-step instruction, so you're in good company.
Cheers
Ed

[GARTHWILSON]

comparison of times taken, at 8MHz, of various types of instructions, on 65c02 and 65816 to x86 (8086? 80286?) and 68K:
http://www.westerndesigncenter.com/wdc/ ... risons.cfm

[yzoer]

Is that a new page? Either way, nice find and kinda confirming what was said here. Nice find

[BigDumbDinosaur]

yzoer wrote:

Is that a new page? Either way, nice find and kinda confirming what was said here. Nice find

It's been there for a while.

What is particularly telling is the interrupt performance.

[barrym95838]

BigDumbDinosaur wrote:

... What is particularly telling is the interrupt performance.

That's the only clear win, IMO. The other timings aren't exactly conclusive or realistic, because equal clock-speed devices did not compete head-to-head with each other in space-time.

Mike

[Aaendi]

I find it funny how a some 68000 fans talk as if numbers and variables magically appear in registers as needed.