68k details

[meynaf]

Originally Posted by ross

[OT]
Just out of curiosity. Is there any actual problem that CLR really can generate?

Taking into consideration only the standard hardware registers (chipset and CIA) the only ones that come to mind that can have side effects are the chipset's STROBEs and CIA's ICRs.
But in any case nothing that can generate serious problems (as long as it's not code out of control..).

For normally written programs, CLR will cause no problem.
It's only pathological cases that can, like this :

 clr.w $dff096
 clr.w $dff09a

In theory no-op. In practice, horrors because the false read will write the last data present on the bus to the register, before clearing it.
One could however argue it's the chipset that's defective and unable to reply correctly to a read...

Originally Posted by ross

Just to get along
You're both right, simply the 6502 if it had a 16-bit bus would access the memory at twice the speed of 68k.
But since we are in the real world, the 6502 actually reads the same data at (if it ever existed) same speed.

Makes me wonder if the two can really run at the same speed.
Isn't a 8-bit bus in some way simpler than a 16-bit one ?

Besides, the 68000 can wait for data to come if something behind is busy. The 6502 can't - it is the master of the bus at any time and leaves the unused cycles for the dma, and if it were pushed to use every possible cycle you wouldn't get any display at all anymore.

[ross]

Originally Posted by meynaf

It's only pathological cases that can, like this :

 clr.w $dff096
 clr.w $dff09a

In theory no-op. In practice, horrors because the false read will write the last data present on the bus to the register, before clearing it.
One could however argue it's the chipset that's defective and unable to reply correctly to a read...

Really? I did not know this. Of course nobody would use those instructions, but I did not think there could be such a side effect.
I thought it was simply a read, of the float value on the bus, and then a writing of 0 in $dff096/9a (so nothing).

[roondar]

Originally Posted by ross

Just to get along
You're both right, simply the 6502 if it had a 16-bit bus would access the memory at twice the speed of 68k.
But since we are in the real world, the 6502 actually reads the same data at (if it ever existed) same speed.

There is such a thing as a 16 bit 6502, it's the 65816 (as found in the SNES). It does just that

The 65816 does have a problem though, it requires rather fast memory to be able to run at full speeds. Which is partly why the better known 65816 based designs tended to run at low clock speeds (Apple II-e @2.8Mhz, SNES @3.5Mhz) until much later on when faster memory came available (but the 65816 was long since out of fashion).

The C64 SuperCPU running at 20Mhz has really fast memory access speeds for instance, but is a 1996 product.

Honestly, I really rather like the 6502. Truly. Even have a special section on them on my website.

Originally Posted by meynaf

Makes me wonder if the two can really run at the same speed.
Isn't a 8-bit bus in some way simpler than a 16-bit one ?

Besides, the 68000 can wait for data to come if something behind is busy. The 6502 can't - it is the master of the bus at any time and leaves the unused cycles for the dma, and if it were pushed to use every possible cycle you wouldn't get any display at all anymore.

The 6502/65C02 was commonly available up to about 4Mhz.

Later on there where some faster versions (including a custom built 1987 Hudson Soft version used in the PC-Engine which ran at 7.16Mhz - though some don't consider that to be a 6502 as it included a bunch of extra instructions and other special hardware features).

So it is possible, but wasn't actually done until memory speeds had increased.

--

Originally Posted by ross

Really? I did not know this. Of course nobody would use those instructions, but I did not think there could be such a side effect.
I thought it was simply a read, of the float value on the bus, and then a writing of 0 in $dff096/9a (so nothing).

The HRM states that reading from write-only chipset values will cause unintended effects (or horrors if you wish )

[plasmab]

Originally Posted by ross

Just to get along

You're both right, simply the 6502 if it had a 16-bit bus would access the memory at twice the speed of 68k.

But since we are in the real world, the 6502 actually reads the same data at (if it ever existed) same speed.

Sigh. People are taking this too personally. I am only interested in comparing the bus interface timing here. No that one CPU is better than the other. Why can’t people ever take what I say in the context I say it...

I was simply pointing out that the 6502 could access RAM faster. It can! That is fact. It has a narrower bus so it’s overall memory throughput is the same. And because the instruction architecture is different the amount of data you can move with a cpu is lower.. I never disputed this.

My point is that if the 68000 had used the same mechanism for its bus interface it would have been way better. It’s my lasting frustration with that chip.

It is my opinion that only getting 0.5mips from 8Mhz is poor given the rest of the hardware in the machine.

[roondar]

Originally Posted by plasmab

I was simply pointing out that the 6502 could access RAM faster. It can! That is fact. It has a narrower bus so it’s overall memory throughput is the same. And because the instruction architecture is different the amount of data you can move with a cpu is lower.. I never disputed this.

Really, the only point I tried to make was that mips ratings are deceptive and clock for clock comparisons are not all that valid if the clock speeds normally differ.

It got a bit out of hand.

Originally Posted by plasmab

It is my opinion that only getting 0.5mips from 8Mhz is poor given the rest of the hardware in the machine.

Lucky us then you actually get 1 mips - the 0.5 mips is only valid for 32 bit instructions, 16 bit ones reach more

I suppose it's still not that much, but hey - it's a 1979 design.

[plasmab]

Originally Posted by roondar

Really, the only point I tried to make was that mips ratings are deceptive and clock for clock comparisons are not all that valid if the clock speeds normally differ.

It got a bit out of hand.


Lucky us then you actually get 1 mips - the 0.5 mips is only valid for 32 bit instructions, 16 bit ones reach more

I suppose it's still not that much, but hey - it's a 1979 design.

Sysinfo reports 0.5mips for a stock 500... is that wrong?

[roondar]

Originally Posted by plasmab

Sysinfo reports 0.5mips for a stock 500... is that wrong?

Sysinfo mips are not that trustworthy as I understand it?

I recall reading the design goal for the 68000 was to get 1 MIPS@8mhz, but I can't find the source for this any more. Anyway, the Motorola FAQ (http://www.faqs.org/faqs/motorola/68k-chips-faq/) claims the following - which seems to agree with the Wikipedia MIPS article (which puts the 8Mhz 68000 at 1.4 MIPS):

CPU       MIPS (VAX MIPS) type      
           8 Mhz     16 Mhz     
_________________________ 
68000                         
68EC000    1.2       2.5

It doesn't help that it all depends on what your definition of MIPS is, as several are used :S

[plasmab]

I’m likely to trust sysinfo over the Motorola marketing bumph though. What does AAIB say?

[meynaf]

Originally Posted by ross

Really? I did not know this. Of course nobody would use those instructions, but I did not think there could be such a side effect.
I thought it was simply a read, of the float value on the bus, and then a writing of 0 in $dff096/9a (so nothing).

It is really a read followed by a write of 0, so in theory harmless (like 6502 reading a second code byte even for one-byte opcodes).
However, write-only Amiga hardware registers interpret a read as if it were a write ! So what happens in reality is that the registers will get written with the last value of the bus instead of providing one...
Big shortcoming of the Amiga hardware IMO. You just can't read the configuration.

Originally Posted by plasmab

I’m likely to trust sysinfo over the Motorola marketing bumph though. What does AAIB say?

Mips are bogus, regardless of the software that gives them.
What does it mean, comparing number of instructions executed per second, when the timing of individual instructions vary ? When two instruction sets are very different ?

[plasmab]

Originally Posted by meynaf

It is really a read followed by a write of 0, so in theory harmless (like 6502 reading a second code byte even for one-byte opcodes).

However, write-only Amiga hardware registers interpret a read as if it were a write ! So what happens in reality is that the registers will get written with the last value of the bus instead of providing one...

Big shortcoming of the Amiga hardware IMO. You just can't read the configuration.







Mips are bogus, regardless of the software that gives them.

What does it mean, comparing number of instructions executed per second, when the timing of individual instructions vary ? When two instruction sets are very different ?

It’s useful for me to see what difference a change to bus timing makes. That’s about all.

The register readback thing is pretty standard across many architectures. Most operating systems kept a copy of them. But with the Amiga you could at least mask off the bits you didn’t want to change.

[roondar]

Originally Posted by plasmab

I’m likely to trust sysinfo over the Motorola marketing bumph though. What does AAIB say?

Assuming the itest does what we need here, it claims 0.58.

Thinking about it a bit more, that does seem somewhat reasonable: 7/0.58 = about 12 cycles per instruction, which is indeed about right. Just goes to show you learn something new every day

Likewise, the BBC Micro claim of 0.5 MIPS is not that far fetched either, 2/0.5 = about 4 cycles per instruction, which is a little bit optimistic but not way off.

Regardless of the above, I still don't really feel using MIPS is a useful measurement for comparing between architectures that are so different. They didn't call it "Meaningless Indices of Performance" without reason

I mean, it's all fine and dandy that the average instruction on the 6502 costs about 4 cycles and the average instruction on the 68000 costs about 12, but these instructions are not really all that comparable in what they manage to accomplish each. You will very often need multiple 6502 instructions to achieve the same as one 68000 one. The reverse isn't true.

But that would be repeating earlier arguments so I'll just stop here

[plasmab]

BBC doesn’t have video contention because of the crack smoking way it’s video system accessed the bus. Somehow manages to access on both edges of the clock. It’s mad.

Of course the Stock BBC B has only got 8 bit registers. So your computing power is half of the Amiga instruction set.

[Leffmann]

About the M68000 performance: my own tests showed about 0.1 MIPS per MHz on average, with the peak performance being 0.25 MIPS per MHz.

To get the numbers I ran SAS/C in a slightly modified Vamos and Musashi, and counted around 15 million clock cycles for 1.5 million executed instructions, for compiling a small program, which I think is a good representation of an average work load.

[plasmab]

Originally Posted by Leffmann

About the M68000 performance: my own tests showed about 0.1 MIPS per MHz on average, with the peak performance being 0.25 MIPS per MHz.

To get the numbers I ran SAS/C in a slightly modified Vamos and Musashi, and counted around 15 million clock cycles for 1.5 million executed instructions, for compiling a small program, which I think is a good representation of an average work load.

I’ll take that figure. 0.8 MIPS. Sure mips isn’t a great measure. This is why Whetstones and Drystones exist.

[roondar]

Originally Posted by plasmab

BBC doesn’t have video contention because of the crack smoking way it’s video system accessed the bus. Somehow manages to access on both edges of the clock. It’s mad.

Not quite as mad as you think, a lot of 6502 based designs used this trick, including multiple designs from Commodore. Edit: wait, you mean that the video chip itself accesses on both edges and the CPU also gets to access on one of the edges? Yeah, that is pretty insane. In a cool way.

Of course the Stock BBC B has only got 8 bit registers. So your computing power is half of the Amiga instruction set.

That's not how it works.

[plasmab]

Originally Posted by roondar

That's not how it works.

I know. But it’s a rough estimate. Lack of registers etc and only one accumulator... yeah I know.

But in the dumbest sense a copy from A to B is what I’m thinking of.

[roondar]

Originally Posted by plasmab

I know. But it’s a rough estimate. Lack of registers etc and only one accumulator... yeah I know.

But in the dumbest sense a copy from A to B is what I’m thinking of.

If you're directly copying a single word from A to B without using address registers (=move.w addr.l,addr.l) then yes, it's exactly 2x faster

For completeness's sake, I will note that if you're copying from A to B and a whole bunch of data needs to be copied or you're copying using address registers, then the 68000 version can be much faster (up to 4x the speed of the 6502 one).

[plasmab]

When you do this kind of stunt on an 8 bit machine you use the stack pointer for either the Source or destination and push/pop as appropriate. So it’s like having one Amiga address register that has the (Ax)- syntax only.

[ross]

Originally Posted by plasmab

So it’s like having one Amiga address register that has the (Ax)- syntax only.

Well, this addressing mode can be really useful! (for a new 68k derived ISA?)
[i'm joking, of course I understood what you meant ]


EDIT: in fact I would not mind at all an architecture with full support of C ++ and -- operators, with pre and post increase..

[coder76]

Here's a list of x86 instruction clock cycles from 8088-Pentium:
https://www.cs.dartmouth.edu/~mckeem...m/doc/x86.html

Compared to a 286, a 68000 seems slow. It's 5 clock cycles for a mov reg,mem and 3 for mov mem,reg. A 68000 takes 8 clocks to move a byte or word from memory to register or register to memory. Also, moving registers to registers is 2 clocks on a 286, while 4 on a 68000.

http://oldwww.nvg.ntnu.no/amiga/MC68...s/timmove.HTML