Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : PALM - The rebirth of Palm Inc. -- Ignore unavailable to you. Want to Upgrade?

To: David E. Taylor who wrote (1491)	8/31/2000 3:15:36 PM
From: TechieGuy-alt	Read Replies (1) \| Respond to of 6784

You guys are talking a bit above my level of understanding of OS's. Would the move to a SrongArm (or other) 32 bit processor and a new 32 bit PALM OS present the same type of problems that MSFT faced when they moved from a 16 bit OS to the 32 bit WIN95/98, where they had to include code to handle the thousands of legacy 16 bit and MSDOS apps that were out there? And if so, would a new 32 bit PALM OS then be more bloated, need more memory, run Well, since I started the original discussion, I'll feel free to explain the issue at hand. If Palm were to move it's handheld line to a different OS (say StrongArm), then the programs out there, that currently run on the Motorola Dragonball (in the current PALM's/visor's/TRg's and CLIe's) would not be able to run natively. Most programs available are in "binary" format. What that means is that the only thing that the program contains is the "raw" instructions to the microprocessor that executes them. The "raw instructions" for a variety of reasons are usually completely different from one processor to the other. That is why, you cannot natively execute a windows program on a sun or alpha machine. The issues that microsoft had when moving from 16bt windows to 32bit windows was not that bad, because the later generation of X86 processors (the 486's ,Pentimus, Athlons etc.) all support native execution of all programs that were designed all the way back to the original 8086! I don't know of any ARM core, or any other core that can execute the Dragonball processors instructions natively. Hence the problem. (and the 2 solutions that I suggested: 1. Have software emulation, 2. Have a dragonball co-processor). TG

To: David E. Taylor who wrote (1491)	8/31/2000 4:01:50 PM
From: Win-Lose-Draw	Read Replies (1) \| Respond to of 6784

First, let me just say thanks for your input to this thread. I look forward to any upcoming comments regarding the QCOM spinoff. And if so, would a new 32 bit PALM OS then be more bloated, need more memory, run slower, and suffer from the stability You specifically pointed at MSFT as an example of problems that can happen, and to that I'll say "It doesn't have to be that way". For starters PALM has an inherent advantage in that the hardware platform is relatively simple and tightly controlled. I'm not a MSFT defender, but it must be acknowledged that the problem of supporting all those peripheral standards is a HUGE one. PALM does not have this problem. A simple way for PALM to do this is pick a new hardware platform with an order of magnitude better performance than the existing one and simply emulate the old system inside the new. It's an old trick, and very nice current examples of this are the emulation programs available for Macintoshes that make it possible for them to be Macs and Win98s and Playstations - all at the same time! This is not simple in the Duncan Hines cake mix sense, but for this industry it's relatively straightforward. Done well the transition could be virtually invisible for the end-user, which to my thinking would be a very, very good thing.

To: David E. Taylor who wrote (1491)	8/31/2000 8:47:53 PM
From: lkj	Read Replies (3) \| Respond to of 6784

David, Going to ARM is a must for Palm OS. Palm has no choice since ARM is clearly the superior processor for the next generation wireless devices. As for going from 16 bit to 32 bit, I don't know how hard it is, but it's certainly in Palm's plan. Already, Motorola is working on a 32 bit Dragon Ball for Palm, so the 32 bit plan has been there for over a year. I think it was you who said that Palm wasn't inventing new stuff. Moving from 16 bit to 32 bit is real progress. Adding WindRiver System's TCP/IP stack is a real progress. (Announced today in WindRiver's CC. I learned this from the WindRiver Thread.) Supporting multiple processor is real progress. These are keys to enable the next generation appliations -- VoIP, MPEG4, JVM..... Too bad that we don't have the Palm OS roadmap, but 4.0 is probably within the next 12 months. Khan