Comments on: 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

I think the more interesting question would be: Which PDA you use most often?

I already assumed that Ed has a wheelbarrow of PDA's, but I'd like to know which one he carries around all the time.


Jim

For example, knowing that many customers are willing to pay a premium for sleek m500-shaped units, Palm could continue to offer them with whatever upgrades they can manage, at least until they can squeeze an ARM into that formfactor. A good tenative product lineup for early 2003 would be as follows:

"low end" <$100 OS4 units,

"premium" OS4 units for $300ish,

and the "super-duper multimedia bells'n whistles" OS5 models for $400 and beyond. Using those three price points as milestones, they can fill the in-between areas with whatever they wish to. Personally, I'd like to see the 66 mhz dragonball make the rounds within Palm's lineup but I have a feeling that ain't gonna happen.

I envision OS4 units sticking around for at least another 6-9 months, probably longer. If anything, Sony's SL100 series, regardless of screen quality, has at least shown that the low-end is in desperate need of some aggressive R&D/price wars so hopefully this will end up bringing some new users into the Palm fold. Perhaps Palm could/should do some sort of "show us your college ID and get a steeply discounted m1xx unit" program? All the college kids I know either don't keep an address book at all, or use their cell phones...

Yes, I think we'll see $200 and lower handhelds running OS 4 with the 66 MHz DragonBall next year. They'll be better at running OS 4 apps than a cheap OS 5 model. They'll help keep the low end going until ARM is practical for that cheap.

p.s. Windows 98 was a bug fix version of Windows 95

Get your facts straight!!

There are no U.S. Pocket PCs that use AAA batteries. Goodness!!

Large spreadsheets are for laptops, not handhelds. Its just not feasable on a small screen.

Databasing solves this better, in my opinion.

Uh - rather than simple word processing, try using a spreadsheet for what it's intended to be used for - MATHEMATICAL CALCULATIONS...and you will quickly see that m515/DTG often has a brain freeze while "Calculating".....you get the equivalent of the "Hourglass" signal.

My 2 cents,

not a ppc troll

Is my analogy correct??????

Not quite. Developers will be able to include some ARM code in their apps. All the OS APIs are written in pure ARM code, which will really speed up alot of apps. It isn't everything that we hoped for but it is enough that developers will be able to write some seriously impressive apps. You can hold off getting OS 5 if you want but your old OS 4 model is going to look pretty sad in a few months.

You should read this, if you haven't already
www.palminfocenter.com/view_Story.asp?ID=3863

Nuff Said

OS 5 already has support for native ARM applications. And thanks to all API functions being native ARM code too, PIM apps (as all other API intensive apps) already run faster under OS5. It DOES show low-end devices running OS 5 are still very much possible.