8M upgrade for the Palm V
on
CeBIT Tidbits
·
· Score: 2
Is offered (or soon to be) by efig (see wfig.com, or www.efig.com, or something like that). They claim they'll charge about $150 to upgrade V, and very short turn around, or you can buy a "new" V from them (no price listed).
The upgrade does void your warentee, but efig will offer their own (apparently on the whole unit), no details on that yet.
So apparently it's a little early yet to decide to buy the upgrade, but it is coming...
Pity 3COM didn't offer a $600, or $550 Palm Vx with 8M. Maybe they will now.
Is "Linux" in the title just to be trendy, or is this book really that pathetically platform dependant? Last time I checked, gtk+ worked fine under Solaris and a slew of other Unixen.
I havn't read the book, I have skimed some of the chaptor drafts during writing. Nothing looks like it was written to only work on Linux, but there are no long discusions of how to get GTK+ for other platforms. There didn't seem to be any Linux specific syscalls or lib calls used, but it's networking code won't work without BSD-style sockets (which Linux and SysVR4 has, but R3 doesn't).
In other words it wasn't written for "all Unixes", but applys to most of them anyway. IMHO, a fine way to write a book that isn't about "Unix Portability" (and no, I don't use Linux, I use FreeBSD, and BSD/OS...and SunOS 4.0.3 holds a special place in my heart, not that I have used it since '92ish)
Anyway, last I checked *BSD systems use gcc. So, BSD did not create a C compiler.
That's mostly irrevlent
BSD didn't need to produce one in part because the FSF allready had, if the FSF hadn't, BSD may well have
There is a C compiler under a BSD style copyright lcc's copyright seems to be a BSD style one
FSF's contrbution is less the C compiler, and more their licence. However I don't plan on claiming that only RMS could have come up with that licence. Progrmmers are by and large inventave people, witness the many licences they have come up with. I find it likely that a GPL style licence would have been invented by someone else if RMS hadn't made it.
You are talking about compiled code, I am talking about hand-tuned code. SGI has good compilers, but they are close to what you can get from the architecture. You can't get much impovement with hand-written assembly on a MIPS (or Alpha) because they are so simple. You can do much better on a SPARC or PPC
So the MIPS sucks because you don't have to hand-code assembly to get good performance? Does that mean the BMW M3 sucks because it gets good 0-60 times with it's automatic transmision?
I've hand coded SPARC assembly, and while I can do better then gcc, I don't beat Sun's compiler. Unless I happen to be using the VIS instructions (only on the UltraSPARC, and not a part of SPARC V9). Does that mean the SPARC sucks too now?
NOTE: the SPARC and MIPS are both quite simple ISAs, but to get good performance on a modern implmentataion of either you need to pay careful attention to the grouping rules, and data dependencies so your SuperSPARC can issue as close to four instructions per cycle as possable, or your Ultra as close to five as possable (sorry, I don't recall the MIPS maximum execution rates, nor the max rates for the Alpha's either). It's actually harder to hand code fast assembly for these beasts then it was back on the old 68020! Or many other assorted CISCs. Then again it isn't my job anymore, so maybe I'm just bad at it now.
Bonus Alpha trivia: the 21264's register rename file is actually two banks of 40 registers each, and if your instruction ends up referencing registers from diffrent banks there is a one cycle penalty. Because these are rename registers they are assigned at runtime, baised on control and dataflow, including effects of mis-prediction. It's basically impossable for a person to figure out how the registers will get renamed, but a really smart compiler could probbably make some good guesses. Not that I have seen a compiler do that mind you, it's just the kind of stuff modern CPUs do that make hand optmising a tripple bitch and a half of a nightmare.
You are forgeting ARM. ARMs code density is awesome. It's like a spiritual successor to 68K. Not surprisingly, ARM and 68K are ruling the embedded market.
Ok, I forgot about the ARM. It's code density isn't all that great, what with losing 4 bits to make every instruction conditional (which is cool, but not very dense), and a few more for the shifter that can apply to every ALU output. Even using the DEC Thumb extension (16bit coding) the code density isn't awesum because your back to a two register ISA, and far branches & big constants are a bitch, but yes it does have the best code density of any RISC if you use the Thumb extension. It's also about 20% slower that way, is it not?
68K is sufficiently fast for most embedded applications. We are talking about people who still use Z80s, for crying out loud.
Sufficently fast for what? The embeded market is very diverse. The folks replacing complex CAMs in washing machines may be just fine with a Z80 (or Z8!), but the folks doing the PlayStation2 want more comp-u-trons. The PalmPilot has a "mere" 16Mhz 68ECxxx in it, and I hear lots of folks that want something faster! The CPU in my thermostat is probbably just fine as a Z80, but the one controling my ABS breaks would be pushing it as a Z80. A 68K may be just fine to control an elevator, but a PostScript laser printer needs a hell of a lot more CPU! A Z80 in my microwave may be overkill, but you need a lot more then that to control a router with a gigabit backplane. I use to do embedded systems (CoinOp video games), beleve me there are embeded systems, and there are embeded systems! I can come up with a bunch more examples where you want more then a 68K, but I think everyone gets the point.
Well, a lot of people use it. I suppose that's because they used Patterson/Hennesy books in their CPU design class at school.
I think it does well in the embeded market because the R4x00 is really damm cheap compaired to any other embeded CPU with similiar performance (or at least it was two years ago, when many of todays products were designed). Go look at the NEC(?) VR4600 prices and tell me the 120Mhz i960 is price competatave! Remember the 4600 has lots of stuff integrated into it as well (not as much as the 68F333, but the 68F333 only runs at 25Mhz!, nor as much as the Cyrex MediaGX, but the MGX is way to costly to see in a cell phone! The MGX's integrated parts are also mostly PC desktop/notebook specific)
IMHO, MIPS is horribly miscast as an embedded architecture. Because it is so streamline, the code density is horrible.
Um, what are you trying to say here? As far as I know the MIPS code density is roughly the same as the SPARC, somewhat better then the ALPHA, around the same as the i960. It's only worse then the CISCs, and the x86 CISCs are gennerally to costly and slow for most embeded applications, so that leaves the 68k and CPU32, both of which are fairly slow compaired to a R4x00 (or an R3000!), or any other modernish RISC.
However it is "just" a bunch of 20Gbit/sec links we need to fill, so "all" we need is something to make use of 20Gb/sec, and to buy a whole buttload of them.
Let's see, I think Juniper's current product is (see http://www.juniper.net/products/m4 0-brochure.htm) capable of 2*8*2.5Gb/sec, or 20Gb/sec as a theoritical max. So in thery you could use a few racks of the highest capacity/highest density routers to drive one of these monsters. In practice I expect it would take at least another spin of Juniper's hardware to do it, but in realiaty they have time for another spin or three before this stuff is likely to be for sale anyway.
I guess we have just solved the "what can we build the backbone out of to support upgrading all the current modem connections to DSL" question...
...have you ever seen the inside of one of the new, low end Sun's? This is a very real market pressure...PCI equipment is common and cheap [...]
Don't forget PCI is also actually better in many ways then Sun's older SBus technology. The "low-end" 33Mhz 32 bit PCI bus has more bandwidth then the 25Mhz SBus (and the older 20Mhz SBus). It is just as easy to identify a PCI card as an SBus one. The only real downsides of PCI from a workstation point of view is that almost all the boot ROMs are Intel specific (the PCI spec defines FCode boot ROMs as well, even gives lipservice to them being "more standard" then x86 boot ROMs, but we all know the score), and the non-technical downside of being "just like a PC".
Yes, I know the PCI bus has no IOMMU like the SBus (not 100% true, AGP is basically a 66Mhz PCI bus with an IOMMU -- one that isn't tipically used). However I think it is at least as hard to keep the IOMMU and multiple-CPU MMUs in sync, as to force the OS to do scatter-gather IO. Unfortunitly that puts a little more burden on the expansion cards to do scatter gather, but high performance cards were going to have to do it anyway...
Let's give Intel their due credit, they finally made a good bus. Every bit as good as the SBus, or the NuBus, or pretty much every other non-mainframe bus that came before it. It may not be a visonary innovation, but it isn't crap either.
Actually, I'm currently working on a program and use ANSI C. But it makes a lot of use of structures and functions to manipulate them, I was wondering if when I use C++ will this give better performance. Particulary I'm using GCC and I heard it was faster than G++.
Yes.
No.
Maybe.
I assume you want to know how fast your code will run, not how fast it will compile. If you are writing C code that does C++ like things (carrying around function pointers in structs, and calling through them) then the C++ won't be slower, and may well be faster (C++ virtual functions have the same effect, but they are frequently implmented somewhat diffrently*, and sometimes the compiler can determine the types ahead of time and code a dirrect jump). C++'s liberies may also help you by supplying an allready optmised data structure so you don't end up using a linked list and linear searches rather then a hash table.
However I can almost garentee you that the first C++ program you write will probbably be slower then the C version you would write, and may well take longer. Not becasue C++ is bad, but because you will be learing both how to weild it effectavly, and efficently. It is probbably time well spent. Think of it like learning lex & yacc, your firt lex/yacc parser will probbably take longer then doing it by hand, but your second lex/yacc parser will be done far faster then doing it by hand. Of corse with lex/yacc there is little diffrence in run time speed, but that can be the case with C++ as well. If you avoid virtual functions and RTTI then your C++ code has no reason to be slower then C (or if you approximate the same features in C, then using the real thing in C++ won't slow you).
* C++ virtual functions are commonally done by having one pointer in the struct point to a virtual function table, so you only have one table per class, not one per instance of the class. Some compilers and platforms also don't store an array of addresses to jump to, but an array of jump instructions. That frequently interacts with modernish CPU branch prediction to be far faster then simple indirect jumps.
Not when i can help it. I have been spoiled for some years now by ANSI prototypes. Of corse if you read the Lion's Commentary on V7 (V6?) Unix you'll see K&R did do it quite a bit!
As i said I tipically only get bit by endeness problems, and rarely by alignment issues. That's why i like to test my code with a Sun and PC client (or peers).
ummmm . . . i've only been writing c code for a few years, so i'm not sure what you're getting at. i can easily imagine stuff like writing ints to a file where you'd have endian problems, but it's a little harder for me to imagine how the compiler would know, or why it would care. i'm also a little bit confused by the idea that linux/intel programmers are inherently any less likely to screw that up.
Stuff written into files, or over a network are the biggest problems in that area. The second biggest is doing unaligned memory accesses (the x86 by default allows 16 and 32 bit operations on any byte boundry, the OS can disable that; RISC CPUs almost never allow unaligned memory accesses, except via "special" slower instructions (like the MIPS loadlo/loadhi, and the SPARC V9 ASI goo)). The alignment issue effects structure padding, so you can't read/write structs from/to files and then just swap bytes around, padding may also be wrong. There are also issues with pointer vs. int size, does a char* fit in an int? Not allways.
In general the idea is that programers who have only used a system that works one way may think that all systems work that way (once known as the "All the world's a VAX" syndrome). More to the point programs only tested on one type of system even if written by programmers who know better can devlope this type of problem. I know, I have written programs on a SPARC, and discovered when porting to an x86 that I forgot to convert from "newtwork" to "host" byte orders in a few places (and I'm talking about less then 5% of the places). Specifically the fear is that the existing "hordes of windows programmers" have only used windows, and to the extent that Linux on the Intel behaves like a Wintel system, they won't learn to do the more portable thing. I expect we will see many programs with binary data files that work on "Lintel" systems, but fail on Linux/SPARC. I also expect a higher percentage of current "Linux" programs can be compiled on non-Linux Unix-ish systems then programs written by folks whos only exposure to a Unix-ish system is Linux. That's not all bad, they won't fear using revoke(2) just because it isn't in Solaris. They won't avoid pthreads(3) merely because SunOS doesn't have it.
are bitwise operations on multiple-byte things non-portable because of that? i guess i always (well, not every day of my life, but you know what i mean:) do things like "foo & (i 12)", so like with a big-endian thing you wouldn't be able to treat bits 0..31 as consecutive? i've mostly ever written code on intel things so i guess i'm naive.
As for the bit shifts, bits 0..31 are consecutive on almost every machine I have used, and on all RISC machines I know of. Also to implment the C standard bit shifts need to work to produce the same results as multiplication or division by powers of two (with possable diffrences in signs), so the shifting you are talking about should be safe.
I have cable, and I don't get it. Who the hell moved it from the common Comedy Central to the uncommon Sci-fi Channel? What percentage of the country even has the ability to view this show anymore???
Damm near 100% (assuming you mean the USA). Check out DishNetwork (www.dishnetwork.com), or USSB/DirectTV, or one of the other Satalite TV services. Now that the FCC has (IMHO, illegally) invalidated even more private contracts, not only can homeowners slip out of restrictave covenents and put up dishes, so can renters! Even if the owner (or covenent) says you can't. The FCC has voided it.
As to whether it's worth the money or not, well that depends on how much your local cable pusdomonopoly sucks, and how expensiave they are, and whate you manage to do to recieve the "broadcast networks". For me it's a big step up from cable. YMMV
Slashdot Mirror
Is offered (or soon to be) by efig (see wfig.com, or www.efig.com, or something like that). They claim they'll charge about $150 to upgrade V, and very short turn around, or you can buy a "new" V from them (no price listed).
The upgrade does void your warentee, but efig will offer their own (apparently on the whole unit), no details on that yet.
So apparently it's a little early yet to decide to buy the upgrade, but it is coming...
Pity 3COM didn't offer a $600, or $550 Palm Vx with 8M. Maybe they will now.
I havn't read the book, I have skimed some of the chaptor drafts during writing. Nothing looks like it was written to only work on Linux, but there are no long discusions of how to get GTK+ for other platforms. There didn't seem to be any Linux specific syscalls or lib calls used, but it's networking code won't work without BSD-style sockets (which Linux and SysVR4 has, but R3 doesn't).
In other words it wasn't written for "all Unixes", but applys to most of them anyway. IMHO, a fine way to write a book that isn't about "Unix Portability" (and no, I don't use Linux, I use FreeBSD, and BSD/OS...and SunOS 4.0.3 holds a special place in my heart, not that I have used it since '92ish)
That's mostly irrevlent
FSF's contrbution is less the C compiler, and more their licence. However I don't plan on claiming that only RMS could have come up with that licence. Progrmmers are by and large inventave people, witness the many licences they have come up with. I find it likely that a GPL style licence would have been invented by someone else if RMS hadn't made it.
So the MIPS sucks because you don't have to hand-code assembly to get good performance? Does that mean the BMW M3 sucks because it gets good 0-60 times with it's automatic transmision?
I've hand coded SPARC assembly, and while I can do better then gcc, I don't beat Sun's compiler. Unless I happen to be using the VIS instructions (only on the UltraSPARC, and not a part of SPARC V9). Does that mean the SPARC sucks too now?
NOTE: the SPARC and MIPS are both quite simple ISAs, but to get good performance on a modern implmentataion of either you need to pay careful attention to the grouping rules, and data dependencies so your SuperSPARC can issue as close to four instructions per cycle as possable, or your Ultra as close to five as possable (sorry, I don't recall the MIPS maximum execution rates, nor the max rates for the Alpha's either). It's actually harder to hand code fast assembly for these beasts then it was back on the old 68020! Or many other assorted CISCs. Then again it isn't my job anymore, so maybe I'm just bad at it now.
Bonus Alpha trivia: the 21264's register rename file is actually two banks of 40 registers each, and if your instruction ends up referencing registers from diffrent banks there is a one cycle penalty. Because these are rename registers they are assigned at runtime, baised on control and dataflow, including effects of mis-prediction. It's basically impossable for a person to figure out how the registers will get renamed, but a really smart compiler could probbably make some good guesses. Not that I have seen a compiler do that mind you, it's just the kind of stuff modern CPUs do that make hand optmising a tripple bitch and a half of a nightmare.
Ok, I forgot about the ARM. It's code density isn't all that great, what with losing 4 bits to make every instruction conditional (which is cool, but not very dense), and a few more for the shifter that can apply to every ALU output. Even using the DEC Thumb extension (16bit coding) the code density isn't awesum because your back to a two register ISA, and far branches & big constants are a bitch, but yes it does have the best code density of any RISC if you use the Thumb extension. It's also about 20% slower that way, is it not?
Sufficently fast for what? The embeded market is very diverse. The folks replacing complex CAMs in washing machines may be just fine with a Z80 (or Z8!), but the folks doing the PlayStation2 want more comp-u-trons. The PalmPilot has a "mere" 16Mhz 68ECxxx in it, and I hear lots of folks that want something faster! The CPU in my thermostat is probbably just fine as a Z80, but the one controling my ABS breaks would be pushing it as a Z80. A 68K may be just fine to control an elevator, but a PostScript laser printer needs a hell of a lot more CPU! A Z80 in my microwave may be overkill, but you need a lot more then that to control a router with a gigabit backplane. I use to do embedded systems (CoinOp video games), beleve me there are embeded systems, and there are embeded systems! I can come up with a bunch more examples where you want more then a 68K, but I think everyone gets the point.
I think it does well in the embeded market because the R4x00 is really damm cheap compaired to any other embeded CPU with similiar performance (or at least it was two years ago, when many of todays products were designed). Go look at the NEC(?) VR4600 prices and tell me the 120Mhz i960 is price competatave! Remember the 4600 has lots of stuff integrated into it as well (not as much as the 68F333, but the 68F333 only runs at 25Mhz!, nor as much as the Cyrex MediaGX, but the MGX is way to costly to see in a cell phone! The MGX's integrated parts are also mostly PC desktop/notebook specific)
Um, what are you trying to say here? As far as I know the MIPS code density is roughly the same as the SPARC, somewhat better then the ALPHA, around the same as the i960. It's only worse then the CISCs, and the x86 CISCs are gennerally to costly and slow for most embeded applications, so that leaves the 68k and CPU32, both of which are fairly slow compaired to a R4x00 (or an R3000!), or any other modernish RISC.
Nothing we have just now.
However it is "just" a bunch of 20Gbit/sec links we need to fill, so "all" we need is something to make use of 20Gb/sec, and to buy a whole buttload of them.
Let's see, I think Juniper's current product is (see http://www.juniper.net/products/m4 0-brochure.htm) capable of 2*8*2.5Gb/sec, or 20Gb/sec as a theoritical max. So in thery you could use a few racks of the highest capacity/highest density routers to drive one of these monsters. In practice I expect it would take at least another spin of Juniper's hardware to do it, but in realiaty they have time for another spin or three before this stuff is likely to be for sale anyway.
I guess we have just solved the "what can we build the backbone out of to support upgrading all the current modem connections to DSL" question...
Don't forget PCI is also actually better in many ways then Sun's older SBus technology. The "low-end" 33Mhz 32 bit PCI bus has more bandwidth then the 25Mhz SBus (and the older 20Mhz SBus). It is just as easy to identify a PCI card as an SBus one. The only real downsides of PCI from a workstation point of view is that almost all the boot ROMs are Intel specific (the PCI spec defines FCode boot ROMs as well, even gives lipservice to them being "more standard" then x86 boot ROMs, but we all know the score), and the non-technical downside of being "just like a PC".
Yes, I know the PCI bus has no IOMMU like the SBus (not 100% true, AGP is basically a 66Mhz PCI bus with an IOMMU -- one that isn't tipically used). However I think it is at least as hard to keep the IOMMU and multiple-CPU MMUs in sync, as to force the OS to do scatter-gather IO. Unfortunitly that puts a little more burden on the expansion cards to do scatter gather, but high performance cards were going to have to do it anyway...
Let's give Intel their due credit, they finally made a good bus. Every bit as good as the SBus, or the NuBus, or pretty much every other non-mainframe bus that came before it. It may not be a visonary innovation, but it isn't crap either.
Yes.
No.
Maybe.
I assume you want to know how fast your code will run, not how fast it will compile. If you are writing C code that does C++ like things (carrying around function pointers in structs, and calling through them) then the C++ won't be slower, and may well be faster (C++ virtual functions have the same effect, but they are frequently implmented somewhat diffrently*, and sometimes the compiler can determine the types ahead of time and code a dirrect jump). C++'s liberies may also help you by supplying an allready optmised data structure so you don't end up using a linked list and linear searches rather then a hash table.
However I can almost garentee you that the first C++ program you write will probbably be slower then the C version you would write, and may well take longer. Not becasue C++ is bad, but because you will be learing both how to weild it effectavly, and efficently. It is probbably time well spent. Think of it like learning lex & yacc, your firt lex/yacc parser will probbably take longer then doing it by hand, but your second lex/yacc parser will be done far faster then doing it by hand. Of corse with lex/yacc there is little diffrence in run time speed, but that can be the case with C++ as well. If you avoid virtual functions and RTTI then your C++ code has no reason to be slower then C (or if you approximate the same features in C, then using the real thing in C++ won't slow you).
* C++ virtual functions are commonally done by having one pointer in the struct point to a virtual function table, so you only have one table per class, not one per instance of the class. Some compilers and platforms also don't store an array of addresses to jump to, but an array of jump instructions. That frequently interacts with modernish CPU branch prediction to be far faster then simple indirect jumps.
Not when i can help it. I have been spoiled for some years now by ANSI prototypes. Of corse if you read the Lion's Commentary on V7 (V6?) Unix you'll see K&R did do it quite a bit!
As i said I tipically only get bit by endeness problems, and rarely by alignment issues. That's why i like to test my code with a Sun and PC client (or peers).
I think Sun's XView (RIP) required it.
Stuff written into files, or over a network are the biggest problems in that area. The second biggest is doing unaligned memory accesses (the x86 by default allows 16 and 32 bit operations on any byte boundry, the OS can disable that; RISC CPUs almost never allow unaligned memory accesses, except via "special" slower instructions (like the MIPS loadlo/loadhi, and the SPARC V9 ASI goo)). The alignment issue effects structure padding, so you can't read/write structs from/to files and then just swap bytes around, padding may also be wrong. There are also issues with pointer vs. int size, does a char* fit in an int? Not allways.
In general the idea is that programers who have only used a system that works one way may think that all systems work that way (once known as the "All the world's a VAX" syndrome). More to the point programs only tested on one type of system even if written by programmers who know better can devlope this type of problem. I know, I have written programs on a SPARC, and discovered when porting to an x86 that I forgot to convert from "newtwork" to "host" byte orders in a few places (and I'm talking about less then 5% of the places). Specifically the fear is that the existing "hordes of windows programmers" have only used windows, and to the extent that Linux on the Intel behaves like a Wintel system, they won't learn to do the more portable thing. I expect we will see many programs with binary data files that work on "Lintel" systems, but fail on Linux/SPARC. I also expect a higher percentage of current "Linux" programs can be compiled on non-Linux Unix-ish systems then programs written by folks whos only exposure to a Unix-ish system is Linux. That's not all bad, they won't fear using revoke(2) just because it isn't in Solaris. They won't avoid pthreads(3) merely because SunOS doesn't have it.
As for the bit shifts, bits 0..31 are consecutive on almost every machine I have used, and on all RISC machines I know of. Also to implment the C standard bit shifts need to work to produce the same results as multiplication or division by powers of two (with possable diffrences in signs), so the shifting you are talking about should be safe.
Damm near 100% (assuming you mean the USA). Check out DishNetwork (www.dishnetwork.com), or USSB/DirectTV, or one of the other Satalite TV services. Now that the FCC has (IMHO, illegally) invalidated even more private contracts, not only can homeowners slip out of restrictave covenents and put up dishes, so can renters! Even if the owner (or covenent) says you can't. The FCC has voided it.
As to whether it's worth the money or not, well that depends on how much your local cable pusdomonopoly sucks, and how expensiave they are, and whate you manage to do to recieve the "broadcast networks". For me it's a big step up from cable. YMMV