Quote:

>>Then he should know I'm right I only have experience with Z80. I did some 80x86 coding, and some ARM (should come in handy when the newMSX arrives ) 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.

Quote:

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.

Quote:

Snout wasn't talking about clockspeed.

Snout mentioned that the R800 is relativly fast for it's 7MHz.

Quote:

'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.

Quote:

>>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.

It may be better than for the z80 to 'off-load' some calculations to the z380.

Quote:

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!

Quote:

>>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.

Quote:

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

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?

Sigh... One last time...

Quote:

When I hear someone saying a Pentium is RISC-based, that is marketing, or not?

LOL, no, that's a technical fact!

Quote:

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. 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.

Quote:

You did say a R800 is Risc 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.

Quote:

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!

Quote:

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.

Quote:

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.

Quote:

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.

Quote:

Sigh... One last time...

OK, here we go...

Quote:

>>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 )

Quote:

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]

Quote:

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 design ]
- One registers is hardwired to zero. [BS, I know, but almost all risc-designs I know of have it]

Quote:

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.

Quote:

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.

Quote:

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.

Quote:

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...

Quote:

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

Quote:

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.

Quote:

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.

Quote:

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.

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

Quote:

>>>>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 )

Ok, in that case I'll explain
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
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
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

Quote:

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
It's like so many ideals, nothing is perfect...

Quote:

- 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
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.

Quote:

- all instructions same size [BS, I know, but still common practise when someone comes up with a risc design ]

This is because same-size instructions make the instruction fetcher and decoder really simple. Less transistors equals cheaper product and faster possible clockspeeds.

Quote:

- 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

Quote:

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')

Quote:

>>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...

Quote:

>>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...

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?

Quote:

Ok, in that case I'll explain

Thanx

Quote:

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

Sparc has a TPC register to store the current PC when a trap occurs. Everything else is left as a exercise for the programmer And most RISC processors don't use stacks for subroutines, but just link-registers. The cpu does not know that there is a stack.

Quote:

>>- 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

But it works to reduce the instruction set. NOP and MOVE can now be done with OR or ADD.

Quote:

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...

Having no stackpointers looks riscy to me And starting a instruction every cycle does too.

Quote:

>>>>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...<< 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?

Well, I thought about:
loop:
decw bc
jr nz,loop
but that won't work, I suppose. (Guessed decw bc would update the flags, the z380 being 16 bit )
Then I would go for:
loop:
addw -1
jr nz,loop
or even:
loop:
ex bc,hl
addw -1
ex bc,hl
jr nz,loop
or:
loop:
ex hl,hl'
- blablabla loopbody blablabla -
ex hl,hl'
addw -1
jr nz,loop
but that doesn't look that fast...
In your first loop A is destroyed. And probably HL is being used in the body, but being the 16 bit accumulator, HL is destroyed anyway, I guess. (It is in most of my loops). The increase in code-size doesn't bother me much (16MB, remember?).
Hmm. Where is that 16 bit djnz?

Quote:

And most RISC processors don't use stacks for subroutines, but just link-registers. The cpu does not know that there is a stack.

- An array of link-registers is still a stack.
- An ARM uses a link-register too, but it still uses a stack for interrupts.

It HAS to work like that, or the user program can be corrupted by an interrupt.
Also there is a big disadvantage to using an array of link-registers in stead of a memory-based stack. What if it runs out? Then you have a pretty big problem.
Anyway, for 'embedded' or specialized operation it's not a big issue, but OTOH in a general computer system with (nested) interrupts coming from everywhere... :/

Quote:

But it works to reduce the instruction set. NOP and MOVE can now be done with OR or ADD.

NOP? Why would anyone want to use NOP except for padding, it doesn't do ANYTHING.
You need a MOVE REG,VALUE anyways, so the only thing having a 0-register does is shortening the codesize. OTOH XOR REG,REG is just as short probably...
Maybe I need practical examples ^^; Just from experience, I don't use 0 very often in a program.

Quote:

(Guessed decw bc would update the flags, the z380 being 16 bit )

nope, the INC/DEC is still the same as on Z80, except it has been expanded to 32 bit.

Quote:

Then I would go for: loop: addw -1 jr nz,loop

Wouldn't work because you most definitely need HL preserved, as it's the 16-bit accumulator.

Quote:

or even: *snip* or: *snip snip* but that doesn't look that fast...

It doesn't indeed.. EX instructions are really slow on Z380, they take 3 cycles (vs. 2 cycles for most others).

Quote:

Hmm. Where is that 16 bit djnz?

^_^ Don't forget the 24-bit one

Quote:

An array of link-registers is still a stack.

Sure, but I meant one link register.

Quote:

An ARM uses a link-register too, but it still uses a stack for interrupts.

No, it does not. The programmer has to push the link register himself.

Quote:

It HAS to work like that, or the user program can be corrupted by an interrupt. Also there is a big disadvantage to using an array of link-registers in stead of a memory-based stack. What if it runs out? Then you have a pretty big problem.

What if you get a page fault when you are trying to push your link adress. Then you are in some serious problems...

Quote:

Anyway, for 'embedded' or specialized operation it's not a big issue, but OTOH in a general computer system with (nested) interrupts coming from everywhere... :/

It is a big issue for embedded or specialized operation. In such systems there are some real time constraints to be met. No one cares if Windows crashes one or two times a hour.

Quote:

>>But it works to reduce the instruction set. NOP and MOVE can now be done with OR or ADD.<< NOP? Why would anyone want to use NOP except for padding, it doesn't do ANYTHING.

To fill branch delay slots, for instance. It's no use to use it for padding since all instructions are the same size anyway... And you can pad your data with any value you want. (But using zero makes sense, of course. Still, nop isn't alway zero ).

Quote:

You need a MOVE REG,VALUE anyways, so the only thing having a 0-register does is shortening the codesize. OTOH XOR REG,REG is just as short probably...

You do not need a MOVE REG,VALUE when you can do ADD r1,r0,5 to move 5 into r1. A MOVE register,register is very different from a MOVE register, value. And ofcourse XOR R3,R3,R3 is as short as ADD R0,R0,R3. The 0-register is also used when you do not care about the outcome...

Quote:

Maybe I need practical examples ^^; Just from experience, I don't use 0 very often in a program.

That's because you program z80,z380,r800 and arm. Having a register hardwired to zero isn't just to load that value into a register...

Quote:

>>Hmm. Where is that 16 bit djnz?<<^_^ Don't forget the 24-bit one

Or the 32 bit version...

But hey I might be now, of course. (So I may give some practical examples in the near future )

Quote:

>>An ARM uses a link-register too, but it still uses a stack for interrupts.<<No, it does not. The programmer has to push the link register himself.

Ok, but that's using the STACK POINTER. Even if it's a manual stack, it's still a stack, with a specialized stack pointer. You can pretend it's just a normal general purpose register, but it's not.

Quote:

What if you get a page fault when you are trying to push your link adress. Then you are in some serious problems...

What if your cat pisses on your mainboard. Then you are in some serious problems...

Quote:

To fill branch delay slots, for instance. It's no use to use it for padding since all instructions are the same size anyway... And you can pad your data with any value you want. (But using zero makes sense, of course. Still, nop isn't alway zero ).

Delay slots suck. It's a cheap hack to save circuitry in branch handling.
About nop, it's indeed not always zero. IIRC, it's EAh on 6502 and x86 doesn't even have a real NOP.

Quote:

A MOVE register,register is very different from a MOVE register, value. And ofcourse XOR R3,R3,R3 is as short as ADD R0,R0,R3. The 0-register is also used when you do not care about the outcome...

Why would you do an operation for which you don't care about the outcome?! :/ And if it was a general purpose register, you could just ignore it. I don't see the practicality in this...

Quote:

>>>>Hmm. Where is that 16 bit djnz?<<^_^ Don't forget the 24-bit one <<Or the 32 bit version...

Actually, there is no 32 bit version! LOL

Quote:

But hey I might be now, of course. (So I may give some practical examples in the near future )

Bah, never mind now... This thread has become way off-topic anyway and doesn't seem to be going anywhere anymore ^^;

Quote:

Ok, but that's using the STACK POINTER. bla ba bla...

No that's storing the link register in memory. You can use any general purpose register for that as A stack pointer. Risc == No specialized stack pointer. Specialized stack pointer == risc based. I guess you still think of the ARM7TMDI as the ultimate risc cpu.
I tried very hard to see your point (right ), so think about this one. Risc == No specialized stack pointer. The reasons ARM advises R13 to be used as a stack pointer are the dsp origin (context switching) and the thumb mode, still there is no hardware stack support... (AFAIK, I have to be careful here ).

Quote:

What if your cat pisses on your mainboard. Then you are in some serious problems...

Hmm, I like my own jokes better...

Quote:

Delay slots suck. It's a cheap hack to save circuitry in branch handling. About nop, it's indeed not always zero. IIRC, it's EAh on 6502 and x86 doesn't even have a real NOP.

Delay slots are a cheap hack to execute a usefull instruction instead of stalling... The fist mips did not stall anyway. It is not a hack; all the first risc cpu's have this feature...
And in modern cpu's it is very stupid to not have a real nop.

Quote:

Why would you do an operation for which you don't care about the outcome?! :/ And if it was a general purpose register, you could just ignore it. I don't see the practicality in this...

Intel did it with the Itanium, so there might be a chance that there is no practicality...

Quote:

>>>>>>Hmm. Where is that 16 bit djnz?<<^_^ Don't forget the 24-bit one <<Or the 32 bit version...<<Actually, there is no 32 bit version! LOL

I was looking for that 16-bit counter version, not the 16 or 24 bit jumps...

Quote:

Bah, never mind now...

I won't. I think it is stupid to waste a resource like registers, so I can not defend it very wel.

I think the newMSX should get a vliw-cpu. Risc is something of the past. Epic has the future. Risc is used to describe everything else... (whahaha).

However, I still got the feeling that having a pipeline is enough for you to call a cpu risc-based...

Quote:

This thread has become way off-topic anyway and doesn't seem to be going anywhere anymore ^^;

So it did seem to be going anywhere?

Back on topic: R800 == 8 bit. With some 16 bit instructions for adresscalculations. 8) And these 16 bit instructions use a 16 bit ALU. Everybody happy.

Quote:

No that's storing the link register in memory. You can use any general purpose register for that as A stack pointer.

No you can't, coz you'll foul up whatever register you are using. The link register and stack pointer are swapped with alternate registers when an interrupt occurs. So you are pretty much forced to use the stack pointer as an actual stack pointer, making it a manual stack, not just 'storing in memory'.

Quote:

I guess you still think of the ARM7TMDI as the ultimate risc cpu.

Indeed I like the ARM architecture (not just ARM7TDMI ) very much, but the fact that it's one of the most popular processors in the world and highly regarded as an efficient RISC CPU is the actual reason I keep bringing it up.

Quote:

Delay slots are a cheap hack to execute a usefull instruction instead of stalling... The fist mips did not stall anyway. It is not a hack; all the first risc cpu's have this feature...

Is it or isn't it a hack? You are contradicting yourself here.

Quote:

Intel did it with the Itanium, so there might be a chance that there is no practicality...

LOL, good one

Quote:

I was looking for that 16-bit counter version, not the 16 or 24 bit jumps...

Doesn't exist, would be cool tho...

Quote:

I won't. I think it is stupid to waste a resource like registers, so I can not defend it very wel.

Bah, then we are in agreement?! WTF were you babbling about before then?

Quote:

I think the newMSX should get a vliw-cpu. Risc is something of the past. Epic has the future. Risc is used to describe everything else... (whahaha).

I think you listened too much to Intel marketing. VLIW might be potentially powerful (if executed right), but it's no fun for assembly programming. ARM is very fun for assembly programmers, so it's a great choice for the new MSX. Any processor that's not easily programmable in ASM falls outside of the MSX philosophy, as far as I'm concerned.

Quote:

However, I still got the feeling that having a pipeline is enough for you to call a cpu risc-based...

How did that thought ever get into your mind? That's almost an insult to my intelligence ^^;

Quote:

Back on topic: R800 == 8 bit. With some 16 bit instructions for adresscalculations. 8) And these 16 bit instructions use a 16 bit ALU. Everybody happy.

And you say you're not stubborn? Besides, I don't know what kind of programs you write, but I tend to use the 16 bit instructions (don't forget INC/DEC belong to those too) for alot more than that!

Quote:

No you can't, coz you'll foul up whatever register you are using. The link register and stack pointer are swapped with alternate registers when an interrupt occurs. So you are pretty much forced to use the stack pointer as an actual stack pointer, making it a manual stack, not just 'storing in memory'.

Your right as long as it concerns ARM. As I said more pure Risc processers do not have specialized stack registers.

Quote:

Indeed I like the ARM architecture (not just ARM7TDMI ) very much, but the fact that it's one of the most popular processors in the world and highly regarded as an efficient RISC CPU is the actual reason I keep bringing it up.

OK, but you are trying to proof your point concerning stack pointers using ARM. There are lots of risc cpu's that don't force you to use a 'special' register as a stackpointer.

Quote:

>>Delay slots are a cheap hack to execute a usefull instruction instead of stalling... The fist mips did not stall anyway. It is not a hack; all the first risc cpu's have this feature...<<Is it or isn't it a hack? You are contradicting yourself here.

No hack.

Quote:

Bah, then we are in agreement?! WTF were you babbling about before then?

It was a great idea to reduce the instruction set, but modern processors need better hints. It is not very smart anymore to execute a sub r2,r2,r2 to load 0 into r2, however in past cpu's it didn't matter. Sorry for the confusion

Quote:

I think you listened too much to Intel marketing. VLIW might be potentially powerful (if executed right), but it's no fun for assembly programming.

Don't worry. And Risc in general isn't fun for assembly programmers anyway...

Quote:

ARM is very fun for assembly programmers, so it's a great choice for the new MSX. Any processor that's not easily programmable in ASM falls outside of the MSX philosophy, as far as I'm concerned.

Very true. I am with you here

Quote:

>>However, I still got the feeling that having a pipeline is enough for you to call a cpu risc-based... <<How did that thought ever get into your mind? That's almost an insult to my intelligence ^^;

Just a feeling...

Quote:

And you say you're not stubborn? Besides, I don't know what kind of programs you write, but I tend to use the 16 bit instructions (don't forget INC/DEC belong to those too) for alot more than that!

OK, I AM stubborn when I think I am right
And I write that kind of program that's never finished... And do you mean I can use INC HL instead of:
push af
ld a,l
add a,1
ld l,a
jr nz,_hup
ld a,h
add a,1
ld h,a
_hup
pop af
8)

Heh, wanted to reply here too, I guess ^_^.
(just making Snout happy)

Quote:

The use of 16 bit loops is faster on z380,

Nonsense. I can program a 16-bit loop on Z80 which is just as fast as an 8-bit loop. Same technique can be used for 24- and 32-bit loops. For more info check http://map.tni.nl/?p=articles/fast_loops.html

Quote:

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).

Ok then, the Z80/R800 has those useful instructions called EX and EXX. With those really fast instructions (1 t-state) you can in total address eight 16-bit registers (and I read the exx-es on the Z380 were really slow, 3 t-states? then you'd better not use them often). Since you already said that that was the max register usage... Also from my own experience, only few routines need more registers than I have available, and those are usually not the critical ones inside loops, which matter most cuz they get repeated often. So in effect the additional registers are easy, probably offer a tiny bit faster code, but no significant advantage, speed-wise.

Quote:

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?

I don't agree. R800 is definately 16-bit, it's the ALU's reach that matters, *not* the external interface, and the ALU handles everything on a 16-bit level. If it didn't, there wouldn't even be a single base of reasoning to claim it's a 16-bit processor (which they did). Ofcourse you can verify this with the original R800 design schematics if you want. (blah). As I said, the external interface doesn't matter shit, it's just the means in which it is connected to the 'outside world'. And if you need an external 16-bit bus that much, it also has a 16-bit external interface. When using OUT (C),r, it outputs the value of C to address lines 8-15, B to 0-7 and r to data lines 0-7. So basically, if you use the common 8-bit I/O addressing space, you can add the value of B to the 7 data lines, and get a 16 bit bus. It's just a matter of wiring and programming things a little differently.

Furthermore, I myself don't know all the details, but I do know that Guyver has very extensive experience with both the Z380 and the R800, being that he programmed the Gameboy Emulator for MSX (GEM) and the Z380 equivalent GEMZ (one of the few actual Z380 applications existing for MSX! And definately the most advanced one), which makes it a perfectly well fit for comparison, and him the perfect candidate for doing so. This is also one of the numerous examples where the code can't detach itself from the 8-bits. The numbers I heard from Guyver were that GEM on an R800 currently runs almost as fast as GEMZ on the Z380. It can still improve and optimizations can still be made, however it is a long way to go from 'just as fast at double clock speed' to 'just as fast at same clock speed'.

Also, don't forget that on the turboR, really a lot of instructions can be executed in 1 T-state. The minimum instruction time on the Z380 is 2 T-states (which is also often met). That fact alone already almost nullifies the entire '16-bit effect', which usually basically offers a shorthand for 2-instruction R800 equivalents. Then take into account that if say, your code is 50% 16-bit (and that's a lot) and 50% 8-bit, that with the common instructions the R800 is 25% faster. This might be compensated with the real power Z380 instructions a bit, but it doesn't happen too often, and as Guyver said, only with extensive use of the multiplication and division instructions it is a realistic scenario that the Z380 is faster.

About RISC, I don't know the exact details about it, but afaik the ARM is one of the ultimate examples of a RISC processor, ne? Or at least a very cool, commonly used one. Ok, I know the ARM . Does the THUMB mode of the ARM processor make it any less RISC? Just think of the R800 as an ARM continuously running in THUMB mode ^_^.

~Grauw

One more thing:

Quote:

- has no microcode (check!) [OK, I did not know that. But are you sure? See instructions like LDIR?]

Well, I don't know what microcodes are, but if LDI hasn't got it, LDIR definately hasn't. All LDIR adds to LDI is conditionally (based on the P/V flag) increase the program counter with 2.

LDI does:
(de)=(hl)
hl++
de--
bc-- (sets P/V flag if not 0)
pc=pc+2

LDIR does:
(de)=(hl)
hl++
de--
bc--
if not(P/V) then pc=pc+2

Doesn't add much functionality of which I'd say 'that doesn't make it RISC'... ARM can execute almost every instruction conditionally, so I highly doubt that conditional PC register increase matters...


~Grauw