Editorial: Low End Handhelds Running Palm OS 5 Unlikely

I can't believe they even make 33 MHz ARM's. That would be like Intel making a 200 MHz P4. Who would buy anything that slow?

http://www.palminfocenter.com/forum/topic.asp?TOPIC_ID=6256

Basically, I asked since there was discussion of ARM processors at slow speeds and that since people were expecting the Palm low-end unit to run OS 5, why were people expecting the SJ20 and SJ30 to run OS 4.1? This answered that by saying that the slower ARM processors will pretty much not be incorporated into pdas anytime soon. Well thanks for at least giving your opinion on the matter.

Haha, Ed I see that everytime you write something that is the least bit opinionated and predictive you write, "I have a horrible track record for predictions..." Don't sweat it, nobody of real importance (meaning excluding trolls) will flame you if you made an inaccurate prediction.

----------
If early to bed, early to rise makes you healthy, wealthy, and wise, does going to bed late make you sick, poor, and dumb?

If you look back at the Intel 286 and compare it to a 386 of the same 16Mhz, you'll know that the 286 is significantly faster.

RISC = Macintosh, Sun, Unix, Etc...

CISC = IBM, Windows 95....XP

CISC has ALWAYS been the more POWERFUL processor of the two BECAUSE of the REDUCED INSTRUCTION SET. IE, you get more power with less instructions!

That's one of the reasons why Unix is used so much in reseach environments, why Macintosh 500Mhz machines compile faster than 1.4Ghz PC's, etc...

Another thing to consider.... the average Unix kernal containts about 7 million lines of code

Compaired to

Windows - about 100 to 250 million lines of code

Hmm,

Which one is more COMPLEX and which one executes programs more efficently???

But AMD has showed us how MHz aren't all. One thing that measures performance a little better is IPC (Instructions Per Cicle). If you can exec more instructions per clock cicle than other similar processor at the same MHz, then you will win. And this is much more easy in RISC because simple instruction have less dependences, less deeper pipelines in case of dependence fault, etc. And all this in a simple CPU design because you don't need complex decoders, not ALU's, etc. And a simple CPU desing also wins in that it can be clocked higher than a complex cpu.

The MIPS cpu is very didactically and you can see there a very very simple risc cpu. There's lot's of resources about it on the net and it exposes the great features of the RISC idea, that is in ALL the new processors core (p4, k7, k8) and the only alternative now to RISC isn't CISC but VLIW found in transmeta and itanium.

Here is the basic difference between the two architectures:
CISC
Clock cycle 1: CPU moves an instruction into register
Clock cycle 2-X: CPU “sets up” the circuit it needs to execute instruction
Clock cycle X+1-X+N: CPU moves any data needed for instruction to execute into registers
Clock cycle X+N+1-X+N+J: CPU executes instruction

RISC
Clock cycle 1: CPU moves an instruction into register
(RISC does not have to setup instruction)
Clock cycle 2-X: CPU moves any data needed for instruction to execute into registers
Clock cycle X+1-X+J: CPU executes instruction

RISC executes in theory N clock cycles faster than a CISC

Of course there are all sorts of other factors, size of data bus, clock speed of data bus, ...

A good example of the “other factors” was mentioned before when someone was talking about comparing the speed of their 16 mhz 286 to their 16 mhz 386. The problem there was that the 386 was a 32 bit processor running on a 16 bit data bus requiring two clock cycles to move one word where the 286 was a 16 bit processor so it could move one word in one clock cycle.

But back to the RISC vs CISC architecture issue, Moor’s Law comes into play here, CISC system designs start to resemble RISC chips because the first thing you do when you have more transistors and you want to speed up your CISC chip (at the same MHZ) is you dedicate more transistors to each instruction, there by reducing the N mentioned above needed to setup the instruction to execute. Think about the speed difference between an AMD 486 and an Intel one…

Ok so that is my two cents worth.

RISC is Reduced Instruction Set Computing
CISC is Complex Instruction Set Computing

Examples of CISC: 80x86 including Pentiums, Dragonball
Examples of RISC: PowerPC, ARM, MIPS

RISC is not Reduced Instruction Computing. It does exactly the opposite of what some said above. It has very few instructions in the *instruction set*, so it is a highly efficient, but very minimalistic instruction set.

CISC tries to speed things up by having more complex instructions that does several things at the same time, but since it is hardware optimized, hopefully it would be fast.

Think of it this way: if you have a box, and you fill it up with sand... obviously it is quite efficient. Now fill it up with pebbles, you waste quite some bit of space (less efficient). RISC is like the sand... very efficient instructions in the instruction set but each does very little. But if the programmer or compiler uses the instructions only as necessary, then it would do well. And because the reduced instruction set has very very simple to execute commands, it permits a much, much faster computer (in clock cycle), which helps go faster.

RISC was supposed to replace CISC. It has not truly happened, but the point is kinda moot as Intel introduced a lot of RISC ideas into the later 80x86.

Regardless, I think it is true to say that you need more clock cycles in a RISC to be competitive to a CISC. The CISC is like a big rock... it does a lot with each instruction. (so add a,b,c is CISC-like... not RISC). RISC on the other hand does very little with each instruction, but can do them very quickly (so add a, b; add a, c is RISC-like).

Unlike the OS that came with Apple's early PowerMacs, the OS code in PalmOS 5 does not contain any 68000 instructions, AFAIK. I strongly doubt that it contains any of the old Kadak OS kernal. It's all new opcodes (maybe without much new fuctionality though...)

Until the majority of the apps are written in native Arm code, a low-end Arm device would be a mistake. Imagine a person buying a cheap Arm Palm, then attempting to run an older Dragonball game on it in emulation? Can you imagine the reviews? It's best that Palm keep the Arm devices in the high-breeds until the majority of the software (including in retail stores) is updated to Arm code.

-------
James Sorenson

I don't want a pocketpc.

So, I will stay with my just bought m130 for a while... :-)

_________
alchemist