What do you mean R800 is 16-bit processor?

Page 2/5
1 | | 3 | 4 | 5

By sjoerd

Hero (593)

sjoerd's picture

21-04-2003, 14:22

Sjoerd, you contradict my statements with claims that have no reasoning behind them.
Hehe. I might have been drunk a the time. oO

RISC is not so much a technology than it is a design strategy that went against the norms of CPU design at that time (early 80's). CISC was invented retroactively to describe anything non-RISC.
OK. But RISC and CISC are terms of the past. Nowadays the good things of both are combined. RISC is used more and more as marketing term to describe something fast.

To make it simple: The time per program equals the number of instructions in the program times the number of cycles per instruction times the time per cycle. Or: Tp/P = I/P x C/I x Ti/C
RISC optimizes the 2nd term, cycles per instruction. CISC optimizes the 1st term, instructions per program. The 3rd term, time per cycle, is affected by the clockrate.

EasySmile

You should be able to deduce from this (and ofcourse all other evidence), R800 is RISC-based while Z80 and Z380 are CISC. BTW, there have been several other RISC-based Z80 implementations, R800 is not unique in that respect.
Still, I think a design is risc when it:
- has no microcode
- starts at least one instruction every cycle
- has lost of general purpose registers, no accumulator, no stackregister
- is a load-store architecture
and so on.

Having a pipeline to overlap fetching, decoding and executing instructions is not enough to call a design RISC imho.

Sure, at 18MHz a Z380 is faster than a 7MHz R800. But clock-for-clock the R800 beats the hell out of Z380! Only in some specially Z380 optimized programs with multiplies and/or divides will it be faster.
In the time it takes a Z380 to do LD HL,DE the R800 can execute LD L,E and LD H,D so there. Want to load A with L'? The R800 can do that almost 3 times faster!

Of course the program should be optimized for z380. It is bs to use only 8 bit instructions on z380. Come on, a Power4 using only 8 bits won't be much faster either.

Really, I love Z380. Linear memory, lots and lots of registers, yeah, this baby rules. But @ 14MHz (standard speed in LPE-Z380, for 18MHz you need a really fast SIMM), it runs comparable to a R800 at 8-bit intensive applications. 32 bits addressing space does add some complexity to a program...
The z380 should be used for 16 bit intensive applications, it will beat a r800 easily.

One has to realize however, R800 can only run this fast in internal memory. Sure, Z380 can probably only run this fast in internal memory too, but with 16MB's of that, who can complain? Tongue
Guess everyone with a PC will complain Tongue

Z380 opens up a whole new world for MSX, that's for sure... Even if for 8-bit applications the speed is 'only' comparable to a R800, when is the last time you plugged a R800-cartridge in your MSX1 or 2? Smile
Just two days ago 8)
And: Z380 == 16 bit => use it for 16 bit applications.

By anonymous

incognito ergo sum (109)

anonymous's picture

21-04-2003, 15:29

Hehe. I might have been drunk a the time. oOYou sound drunk now too ^^;
OK. But RISC and CISC are terms of the past. Nowadays the good things of both are combined. RISC is used more and more as marketing term to describe something fast.That's all well and good, but the processors we're talking about here are respectively 9, 13 and 26 years old! Besides, if you think 'RISC' is just a marketing term then you are sadly mistaken.

Still, I think a design is risc when it:
- has no microcode
- starts at least one instruction every cycle
- has lost of general purpose registers, no accumulator, no stackregister
- is a load-store architecture
and so on.
Starting an instruction every cycle is something an ARM can't even do! Are you calling that non-RISC? R800 satisfies most (if not all) of those points.

Having a pipeline to overlap fetching, decoding and executing instructions is not enough to call a design RISC imho.I never said it was.

>> In the time it takes a Z380 to do LD HL,DE the R800 can execute LD L,E and LD H,D so there. Want to load A with L'? The R800 can do that almost 3 times faster! <<

Of course the program should be optimized for z380. It is bs to use only 8 bit instructions on z380. Come on, a Power4 using only 8 bits won't be much faster either.
I compared an optimized 16 bit against the 8 bit equivalent running on R800, stating the R800 executes those 8 bit instructions in the same amount clock cycles as the Z380 does its 16 bit. So I don't see your point here.

Stating all Z380 must be written in 100% 16 bit is strange, some problems are 8 bit in essence, creating a 16 bit solution does not make it any faster.

>>Z380 opens up a whole new world for MSX, that's for sure... Even if for 8-bit applications the speed is 'only' comparable to a R800, when is the last time you plugged a R800-cartridge in your MSX1 or 2? Smile<<
Just two days ago 8)
And: Z380 == 16 bit => use it for 16 bit applications.

Again your statements make no sense.

By anonymous

incognito ergo sum (109)

anonymous's picture

21-04-2003, 15:58

Then he should know I'm right Big smile
I only have experience with Z80. I did some 80x86 coding, and some ARM (should come in handy when the newMSX arrives Smile ) And very little Sparc-stuff.

So basically you have no experience on Z380 or R800, then how can you compare those two and make any valid claims?
My experiences are mainly with Z80, R800, Z380, 80x86, ARM. Furthermore I have studied several other RISC architectures, RISC and non-RISC Z80 implementations, 32-bit Z80 derivatives (like Toshiba's TLCS-900), 6502-family, 68000, and the inner workings of Post-RISC x86 (Pentium III/IV, Athlon) and ARM processors.

A cpu is as fast as it is. You can't compare cpu's by just looking at the clockspeed. The reason I call it a 8 bit processor is that most ALU instructions work on 8 bit. Only some adressing calculations are 16 bit.Snout wasn't talking about clockspeed.
The ALU of a Z80 is 8-bit, the ALU of a R800 is 16-bit. The instructionset it provides has nothing to do with that.

You should not expect te instructions to be 32 bit. The Z380 is 16 bit because the ALU instructions are at most 16 bit, with te exception of some adresscalculate instructions which are 32 bit.
'Some adresscalculate' instructions? I'm sorry, but that 'some' are about all of Z80's 16-bit instructions that have been expanded to 32-bit. And again, it's a technical fact the Z380 ALU is 32 bit, regardless of the amount of 32 bit instructions available.

And the fact that on MSX a lot is still done by the Z80 should just speed things up, I guess.Again you are talking about something you apparently don't know anything about. The LPE-Z380 'off-loads' all I/O to the Z80 because the Z380 has no direct access to the internal MSX devices (VDP, PSG, etc). This is definitely not to speed things up, in fact it is often slower.

Your statements seem to be based on a 'feeling' rather than technical facts. Therefor I will not discuss this any further with you.

By sjoerd

Hero (593)

sjoerd's picture

21-04-2003, 16:20

Could be that I still sound drunk now. But I am not. Heheh. Really. The fact that the processors we are talking about here are old, older and very old does not mean RISC and CISC are not terms of the past. As you said, CISC was invented to describe every cpu that was different from mips and sparc-like cpu's. When I hear someone saying a Pentium is RISC-based, that is marketing, or not?

>>Still, I think a design is risc when it:
- blablabla Smile<<
Starting an instruction every cycle is something an ARM can't even do! Are you calling that non-RISC? R800 satisfies most (if not all) of those points.

Starting (or better: finishing) at least one instruction per cycle was THE aim of RISC when the term was introduced: making instructions simple enough to execute in one cycle. (so: Reduced Instruction Set Computer, all instructions that take longer to finish were removed). But that is as far as I know, of course. oO RISC is used to describe other things than it did in the past.

>>Having a pipeline to overlap fetching, decoding and executing instructions is not enough to call a design RISC imho.<<
I never said it was.

You did say a R800 is Risc Smile What other RISC-like features does the R800 have? The ISA doesn't look very Risc to me, for instance.

I compared an optimized 16 bit against the 8 bit equivalent running on R800, stating the R800 executes those 8 bit instructions in the same amount clock cycles as the Z380 does its 16 bit. So I don't see your point here.
Stating all Z380 must be written in 100% 16 bit is strange, some problems are 8 bit in essence, creating a 16 bit solution does not make it any faster.

The use of 16 bit loops is faster on z380, loading and storing 16 bit values in memory is faster, logical operations are faster on z380. Some problems are 16 bit in essence, creating a 8 bit solution does not make it any faster. The use of more registers makes z380 optimized code faster because you'll have to use the memory a lot less. (Okay, I know: There are no algorithms that need more than 8 registers).
And XORW HL,DE looks faster than LD A,H/ XOR D/ LD H,A/ LD A,L/ XOR E/ LD L,A, to me.

Again your statements make no sense.
That does not mean I am not right, am I right? Crying

The point here was: R800 == 8 bit. Not: R800 is not RISC. (But it is not, of course).
But I really would like to know: What makes the R800 risc-based? Why is the z380 more cisc-based?

By sjoerd

Hero (593)

sjoerd's picture

21-04-2003, 16:39

>>Then he should know I'm right Big smile
I only have experience with Z80. I did some 80x86 coding, and some ARM (should come in handy when the newMSX arrives Smile ) And very little Sparc-stuff.<<
So basically you have no experience on Z380 or R800, then how can you compare those two and make any valid claims?

I can't.

My experiences are mainly with Z80, R800, Z380, 80x86, ARM. Furthermore I have studied several other RISC architectures, RISC and non-RISC Z80 implementations, 32-bit Z80 derivatives (like Toshiba's TLCS-900), 6502-family, 68000, and the inner workings of Post-RISC x86 (Pentium III/IV, Athlon) and ARM processors.
I have read some advertisement-stuff on alpha, hppa, amd x86-64, arm, itanium, mips64, pentium4, sh5, Power4, sparc, tm1300, z380 and z80. But I had no idea what they were talking about, to be honest. Crying

Snout wasn't talking about clockspeed.
Snout mentioned that the R800 is relativly fast for it's 7MHz.

'Some adresscalculate' instructions? I'm sorry, but that 'some' are about all of Z80's 16-bit instructions that have been expanded to 32-bit. And again, it's a technical fact the Z380 ALU is 32 bit, regardless of the amount of 32 bit instructions available.
And the 8 bit instructions are just expanded to 16 bits... I did not state the ALU is not 32 bit.

>>And the fact that on MSX a lot is still done by the Z80 should just speed things up, I guess.<
It may be better than for the z80 to 'off-load' some calculations to the z380.

Your statements seem to be based on a 'feeling' rather than technical facts. Therefor I will not discuss this any further with you.

Yeah! Do not talk to me, I am stupid! Evil

By snout

Ascended (15187)

snout's picture

21-04-2003, 16:45

>>Snout wasn't talking about clockspeed.<<
Snout mentioned that the R800 is relativly fast for it's 7MHz.

I think making this statement made sence, because the R800 is Z80 based. However, running Z80 code on a R800 runs more than twice as fast than on a Z80.

Yeah! Do not talk to me, I am stupid! Evil

Hmmm... ^_^
This discussion has now moved from 'is R800 16 bit or not?' to 'is R800 risc or not?'. Both GuyveR and Sjoerd have said what they had to say about it. Maybe some other MSX coders have something to say about the things mentioned earlier in this thread? What makes a processor RISC, what doesn't?

By anonymous

incognito ergo sum (109)

anonymous's picture

21-04-2003, 17:02

Sigh... One last time...

When I hear someone saying a Pentium is RISC-based, that is marketing, or not?LOL, no, that's a technical fact!

Starting (or better: finishing) at least one instruction per cycle was THE aim of RISC when the term was introduced: making instructions simple enough to execute in one cycle. (so: Reduced Instruction Set Computer, all instructions that take longer to finish were removed). But that is as far as I know, of course. oO RISC is used to describe other things than it did in the past.
No, the aim was to implement a simple instruction set, resulting in that one could try to finish an instruction every cycle. It doesn't always work that way, not even in the purest of RISC processors.

You did say a R800 is Risc Smile What other RISC-like features does the R800 have? The ISA doesn't look very Risc to me, for instance.
Well, from the features you named:
- has no microcode (check!)
- starts at least one instruction every cycle (this is bullshit)
- has lost of general purpose registers, no accumulator, no stackregister (this is also bullshit, RISC processors (even ARM) have stacks too, and they can have one or more accumulators too)
- is a load-store architecture (ok, there are some load-modify-store instructions, so I'll give you this one)

Ofcourse the ISA doesn't look very RISC, it's Z80-compatible! What do you expect? ^^;
Your notion of what RISC means is still very narrow... I never said R800 is a pure RISC, I said R800 is a RISC implementation of the Z80 architecture.
When looking at all RISC processors, there are only very few that are 'pure RISC'. In fact, 'pure RISC' doesn't exist, not even theoretically.

The use of 16 bit loops is faster on z380, loading and storing 16 bit values in memory is faster, logical operations are faster on z380.
You must know a trick I do not, because loops have not changed in speed on Z380.
Nor is loading and storing 16 bit values faster on Z380, in fact R800 is a lot faster!

Some problems are 16 bit in essence, creating a 8 bit solution does not make it any faster. The use of more registers makes z380 optimized code faster because you'll have to use the memory a lot less. (Okay, I know: There are no algorithms that need more than 8 registers).
And XORW HL,DE looks faster than LD A,H/ XOR D/ LD H,A/ LD A,L/ XOR E/ LD L,A, to me.

I'm definitely not arguing against that! You are right, Z380 is 3 times faster on that 16 bit XOR.
Unfortunately mosy programs are not pure 16 bit. I already said the Z380 has a lot of potential, for instance the 4 complete register sets allow for very fast context-switching.

Most of the speed of Z380 comes from the fact that it runs at double the R800 frequency. A good rule of thumb is: 14.32Mhz Z380 worst-case ~= 7.16MHz R800 best-case.
Still, as I said before, clock for clock the R800 is a lot faster for most Z80-compatible instructions.

The point here was: R800 == 8 bit. Not: R800 is not RISC. (But it is not, of course).
But I really would like to know: What makes the R800 risc-based? Why is the z380 more cisc-based?
You have given no valid arguments to R800 being 8-bit and non-RISC, you conclusions seem to be written in stone and based on fluff.
As for those last questions, they have been answered either directly or implicitely already and are fairly obvious to me.

This really is my last reply as this thread is beginning to run in circles. You obviously have made up your mind about "what is" and "what isn't" even though you provide no technical back-up. I can't argue against stubbornness.

By anonymous

incognito ergo sum (109)

anonymous's picture

21-04-2003, 17:23

Maybe some other MSX coders have something to say about the things mentioned earlier in this thread? What makes a processor RISC, what doesn't?
Another interesting processor I forgot to mention earlier, is the Z80 (or one can argue 8080) implementation in the GameBoy (classic and Color). This CPU seems to be very similar in design to the R800, with the difference being it is 8-bit. The 8-bit or 16-bitness becomes clearly visible when you put Z80, R800 and Gameboy's CPU instruction timings in a table.

By sjoerd

Hero (593)

sjoerd's picture

21-04-2003, 17:48

Sigh... One last time...
OK, here we go...

>>When I hear someone saying a Pentium is RISC-based, that is marketing, or not?<<
LOL, no, that's a technical fact!

OK. (I am learning here Smile )

No, the aim was to implement a simple instruction set, resulting in that one could try to finish an instruction every cycle.No it was: making instructions simple enough to finish one every cycle. [hehe, edit]

It doesn't always work that way, not even in the purest of RISC processors.It does work this way in pure RISC processors. On the other hand: there seem not to be any pure RISC processors.

Riscy features?
- has no microcode (check!) [OK, I did not know that. But are you sure? See instructions like LDIR?]
- starts at least one instruction every cycle (this is bullshit) [I know, just the thing that started the 'risc movement']
- has lots of general purpose registers, no accumulator, no stackregister (this is also bullshit [This is not bullshit], RISC processors (even ARM [is arm your definition of Risc?]) have stacks too [I meant no dedicated stackregisters, with risc processors all registers could be used as stackpointer; arm is not pure risc], and they can have one or more accumulators too [I meant all registers can be used as accumulator, so add c,b would be possible])
- is a load-store architecture (ok, there are some load-modify-store instructions, so I'll give you this one) [Thanx]
- all instructions same size [BS, I know, but still common practise when someone comes up with a risc designSmile ]
- One registers is hardwired to zero. [BS, I know, but almost all risc-designs I know of have it]

Ofcourse the ISA doesn't look very RISC, it's Z80-compatible! What do you expect? ^^;
I do not expect a R800 to be RISC.
Your notion of what RISC means is still very narrow... I never said R800 is a pure RISC, I said R800 is a RISC implementation of the Z80 architecture.
I know. And of course the notion of what RISC means should be very narrow, it loses its meaning when I call every cpu risc-based.
When looking at all RISC processors, there are only very few that are 'pure RISC'. In fact, 'pure RISC' doesn't exist, not even theoretically.
Pure RISC does exist theoretically.

You must know a trick I do not, because loops have not changed in speed on Z380.I was talking about the loopcounters, incrementing and checking them...

Nor is loading and storing 16 bit values faster on Z380, in fact R800 is a lot faster!Strange, but I was just guessing here, sorry Smile

You have given no valid arguments to R800 being 8-bit and non-RISC, you conclusions seem to be written in stone and based on fluff.
8 bit: based on the point of view of a programmer. 8 bit instructions with some 16 bit instructions aimed on adresscalculations.
non-RISC: z80 opcodes. A so called risc based pentium at least breaks up the instructions in new simpler instructions that are executed by a risc-like core.

As for those last questions, they have been answered either directly or implicitely already and are fairly obvious to me.
Not to me. I can see why you say: r800 is 16 bit/z380 is 32 bit. But r800 is risc based, z380 is not? I just do not see it.

This really is my last reply as this thread is beginning to run in circles. You obviously have made up your mind about "what is" and "what isn't" even though you provide no technical back-up. I can't argue against stubbornness.
I am not stubborn. But I do have a strong feeling about what should be called risc and what not. I just do not see the difference between r800 and z380 here.

By anonymous

incognito ergo sum (109)

anonymous's picture

21-04-2003, 23:57

Stepping away from the R800/Z380 risc/non-risc discussion Tongue


>>>>When I hear someone saying a Pentium is RISC-based, that is marketing, or not?<<
LOL, no, that's a technical fact!<<
OK. (I am learning here Smile )

Ok, in that case I'll explain Smile
The instruction decoder of modern x86 processors (which are inherently INCREDIBLY CISC with instructions like MOV EAX,[EBX+ECX*6+1000h]) decodes instructions into RISC instructions. AMD calls them macro-ops, Intel something else I think... An instruction like that complex MOV might decode into MUL R1, ECX,6 + ADD R2,EBX,R1 + ADD R3,R2,1000h + MOV EAX,[R4]. This is purely guesswork, but it's the principle that counts Tongue
Internally a modern x86 CPU has hundreds of registers which are used by those internal opcodes together with the register-renaming hardware.
In a sequence of x86 instructions, these internal instructions can be mixed together and paired for most efficient execution.

Interestingly, VIA C3 processors have secret modes with alternate instruction sets with extra registers and less CISC-shit Tongue
Also, Transmeta x86 processors are internally a VLIW processor (similar to Itanium) and use a processor-internal software layer that does dynamic recompilation to execute x86 transparently.
In the x86 world nothing is what it seems anymore Smile

It does work this way in pure RISC processors. On the other hand: there seem not to be any pure RISC processors.My point exactly Smile
It's like so many ideals, nothing is perfect...

- has lots of general purpose registers, no accumulator, no stackregister (this is also bullshit [This is not bullshit], RISC processors (even ARM [is arm your definition of Risc?]) have stacks too [I meant no dedicated stackregisters, with risc processors all registers could be used as stackpointer; arm is not pure risc], and they can have one or more accumulators too [I meant all registers can be used as accumulator, so add c,b would be possible])
The problem with all registers being usable as stackpointer is that you have a problem when there is an interrupt. This is why even RISC processors that CAN use all registers as stackpointer have an internal or 'system' stackpointer for interrupts.

BTW, ARM is not my definition of RISC, but it is currently one of the most popular ones Smile
Actually that is the whole point, there is no definition of RISC. It's just a collection of ideas, some of which can't practically be used together.

- all instructions same size [BS, I know, but still common practise when someone comes up with a risc designSmile ]This is because same-size instructions make the instruction fetcher and decoder really simple. Less transistors equals cheaper product and faster possible clockspeeds.

- One registers is hardwired to zero. [BS, I know, but almost all risc-designs I know of have it]Indeed, it's just one of those idea's in the RISC-pool. I don't like it tho Tongue

I know. And of course the notion of what RISC means should be very narrow, it loses its meaning when I call every cpu risc-based.
Hehe... Well, since there are no pure RISC processors, you couldn't call any processor RISC then. The thing is, RISC is pretty wide.. Just not as wide as CISC (which just means 'everything else')

>>When looking at all RISC processors, there are only very few that are 'pure RISC'. In fact, 'pure RISC' doesn't exist, not even theoretically.<<
Pure RISC does exist theoretically.

If there's a theory describing a pure RISC I still have to see it. However, RISC being a big pool of thoughts about processor design, there are plenty of ideas that aren't compatible with eachother, like the stack pointer thingy...

>>You must know a trick I do not, because loops have not changed in speed on Z380.<
You mean:

loop: ;...
DEC BC
LD A,C
OR B
JR NZ,loop

versus:

loop: ;...
DEC BC
LD HL,BC
ORW BC
JR NZ,loop

?
All I see in the latter is HL being destroyed, a register you are probably using in the loop body, and a increase in code-size. Maybe you can teach me? Smile

Page 2/5
1 | | 3 | 4 | 5
My MSX profile