I know that the audience for Tom HW Guide, etc is primiarily interested in general purpose programs and games. It would be nice if there was a hardware review site (or paper mag) that was targetted towards the technical user a bit more. Even CAD mags manage to carry the odd HW review in them but have you ever seen a software publication reviewing software development hardware?
As for Q3A... I'm too busy waiting for my compile to finish;)
Having read a couple of Spitfire (I can't bear to say Duron) and Thunderbird reviews I am struck by just how irrelevant the performance figures are to me. Like a lot of Slashdot readers I do a *lot* of software development and spend forever watching gcc, msvc and Delphi chew processor cycles. I'd give anything to find out the most effective platform for what I do.... how quickly Word loads or Q3A runs is not likely to be representative. The few benchmarks that these sites run that do involve a compiler (some of the Spec* tests use gcc and the ZD Content Creation bm uses msvc AFAIK) never quote the results separately from the whizzy 3D piccie software.
Wouldn't it be great if we could get hardware reviews of setups that software developers are likely to want. Is the Thunderbird really quicker than the Coppermine and Spitfire for building Mozilla on Linux(or Windows)? Is it worth paying for SCSI or is that PC266DDR SDRAM what we should hold out for?
Re:x86 is popular to hate, but not that bad really
on
Is The x86 Obsolete?
·
· Score: 1
>If you take all of this out, you pretty much >have a RISC chip. And you'd still be compatible >with 95% of the code that runs on the Pentium II >and III. I expect we'll be seeing this kind of >thing soom from either Intel or AMD.
This is exactly what Motorola did a couple of years ago with the ColdFire which is an m68k chip with all of the naff or complex instructions stipped out. They call it Variable Length RISC because it has a reduced instruction set (which runs a lot quicker) but still retains the compact opcodes of the m68k family. Getting rid of the junk means that a (non-superscalar) ColdFire is a *LOT* faster clock for clock even when compared with the superscalar 68060.
One feature which might be of interest from an x86 legacy code standpoint is that you can run m68k on a ColdFire with the aid of an efficient emulation library that traps illegal opcode exceptions and emulates the instructions. If you pick your instruction carefully the hit from this _should_ be minimal.
Of course if Motorola had done to the ColdFire/m68k what AMD/Intel have done to the x86 the PowerPC would be extinct.... well we can dream;)
Yeah right. The pigs are fueled, watered and ready for take off.
Whilst what you say is all true. To achieve equal functionality with Linux rather than QNX or RTEMS will require a lot of bloat. Linux is bloated. I've spent the last couple of months working on a contract using ucCLinux which is the most pared down version yet. Trust me, Linux is bloated for deeply embedded systems like the iopener.
In many respect Linux is like Window CE (except that CE has better realtime response). All hype, lots of eager followers and very little performance. The only thing it has going for it is that it is Open Source. Keep it on the goddamn desktop where it belongs! (and does a very good job thankyou)
>1. a linux/gui combon in 8mb of flash vs the >10mb that QNX uses
This is deeply unlikely...
Linux is just too fat. Getting a version of text mode linux with out any gui into 8MB of flash it is tough enough (the IOpener doesn't have a lot of ram so compressed RAM disks are going to have to be damn small). Getting a halfway decent lightweight web browser and micro GUI to sit ontop of that is also more than a little difficult.
A more credible solution would be to consider one of the Open Source Real Time embedded operating systems like <a href="http://sourceware.cygnus.com/ecos/">eCos</a> or more likely <a href="http://www.rtems.com">RTEMS</a> running <a href="http://microwindows.censoft.com/">Microwindo ws</a>. This would possibly leave enough room in the flash for offline message stores and the like if required.
Thanks for injecting a dose of normality. I was getting worried that this was going to turn into a "It made my girlfriend pregnant just because she looked at it" stampede panic;)
I2O is pretty naff from a software standpoint. The i960 that is used for the IO processor (hey they used to use Z80s for this!) runs vxWorks. Couldn't they have used an open source "alternative" like RTEMS?
At the moment Mozilla is too tied to the Javascript engine and not enough of the interfaces are accessable through XPIDL generated interfaces which makes wiring up another scripting engine difficult.
This is all set to change however but not till after the first release. When all the relevant interfaces are represented(or representable) in XPIDL it should happen...this will also make embedding the browser much easier too.
Thank you for pointing out the differences between the Scottish Law system and the English/US/Austrialian law system. Not a lot of people know that;)
There is an interesting point in here though... Demon used to be an English company but was bought a while back by Scottish Power for their Scottish Telecom subsidiary which is now known as "Thus(tm)" (Nearly as stupid as Inprise). Of course Demon didn't move their NOCs up to Scotland (too damn expensive for little gain) but in a case like this would the defamation claim be held under English Law (because the servers & claimant were in England) or under Scottish Law because the company was Scottish?
Or maybe it's all irrelevant because it happened before the buy out?
The problem with Real Time response has nothing to do with writing the thing in assembler. You can write buggy non-deterministic code in any language and in many ways "big computer" assembler encourages this. Most true real time operating systems these days are written in C (e.g. RTEMS or eCos - both are open source examples).
The big problem (OS/kernel level patches aside) is, I suspect, more the _way_ Linux applications are generally built. Most "big computer" (i.e. Windows, Linux, etc) programmers don't understand how to build deterministic real-time code. From a conventional app standpoint you would never contemplate pre-allocating all dynamic memory structures, tasks, etc but this is absoutely necessary to provide the necessary deterministic response required of a real-time program. Most app developers will choose the solution that provides the highest speed for the common case - real time systems often take a performance hit on the common cases to ensure that *all* cases meet the deadline. Designing a multi-threaded application to be responsive, not suffer priority inversion, etc,etc is tough.
One of the good things to note though is that there is a lot of Open Source real-time work going on out there with RTEMS, eCos and RTLinux providing a sound platform for developers to learn and use real-time techniques.
You could always have a national health service like more civilised parts of the world....you know where medical care is given on the basis of need rather than what type of job you have.
Sorry. That's a bit harsh but, (like GSM mobile phones), true.
NT (or more correctly NTFS) has had hardlink support for ages. This was needed for it's "POSIX" subsystem (which is now decrepit). This feature is used heavily by the Cygwin project(http://sourceware.cygnus.com/cygwin/) to emulate unix hard links.
There is no equivalent of a symlink in NT though. Shortcuts are nothing like symlinks as people have pointed out;)
You can use sym and hard links within Cygwin but it emulates the symlinks by creating a file with a pointer to the correct location. Everything works as planned if you use Cygwin hosted tools (bash, cp, mv, etc) but it gets horribly confused when you move symlinked things arond with explorer;)
Hmm... Given the existence of GCC, maybe they will open source or drop the compiler, and sell the IDE only instead.
I hope not. The Borland compiler has a lot of advantages, the main one being speed. The Delphi 4 compiler will build my 100k line application from scratch in around 60sec on a PII-233+192MB RAM. An equivalent sized C application can take ~10mins (under Linux - much much more under Windows/Cygwin)....
GCC however is highly portable and can target many platforms and processors. Which is really neat....but you don't need (or want) an IDE to do that. Autoconf/Automake is your friend;)
There are currently two Open Source pascal projects:
- Free Pascal: Written in itself, has a lot of extensions over "standard" Pascal which bring it _close_ to Borland Pascal. Available for a few non-x86 platforms. - GNU Pascal: Written as a language front-end to GCC(GNU Compiler Collection;) so can target virtually any platform that GNU C can and is highly optimising. Supports a wide variety of Pascal standards. Somewhat compliant with Borland Pascal.
Neither of these compilers are in the same league as Borland Delphi. They are both staggeringly slow compared with the Borland compilers (OK, I can forgive GNU Pascal as it shares exactly the same back end as GCC). Neither compiler has adopted many Delphi-isms - which is good if you want a Borland Pascal look-a-like but lousy if you have 100k+ lines of Delphi (like me;). Both compilers are cross-platform and cross-processor which is a Good Thing(tm).
When I looked at trying to improve these projects back in 96/97 the developers seemed less than enthusiastic about adopting Delphi constructs... YMMV.
- It removes the little used features and arcane characters. - Has excellent, easy to use, _reliable_ exception handling. - Has *strong* typing for improved productivity. - Compiles quickly to code of comparable quality to C++.
Unfortunately the language has been hijacked by Borland/Inprise with it's proprietary (but excellent) implementation. Also no sane programmer would use Pascal because it makes your code easy to read and of course, as far as jobs are concerned, obsurity = security;)
Having read through the stuff that this guy has figured out it looks like there is way too much junk in there.
The cartridge interface is pretty much entirely hooked up to the RCP. Who knows what all is in that chip... If it were me I would put a small amount of ROM in there with an unmodifiable boot monitor that checked the validity of the cartridge. I would also have a nasty bus interface to the cartridge to make it a bit tougher on Mr Joe Hacker.
It's a shame that they didn't put the bus of the VR4300i on the cartridge slot with ~CSBOOT(or whatever that is in MIPS-speak)... Then you'd just need to hookup a bit of FLASH to run the OS of your choice. A number of OpenSource OSs would run on an N64: RTEMS, eCos and I guess Linux. Linux would be the least favoured option. This is because 4MB is not a heck of a lot for a 64bit MIPS machine running bloatware (compared to RTEMS or eCos) like Linux.
Fo more info on RTEMS see http://www.rtems.com/ For more info on eCos see http://sourceware.cygnus.com/
I agree....some even have a series of Broadway Musicals as well;)
It's a real shame because there were quite a few nominations for _genuine_ unsung heros who have really made a difference to the project they worked on. I guess that this is the nature of the beast though. If they are unsung heros then people are hardly going to recognise them or their work.....:(
There are many well known Open Source OSes that are suitable for embedded systems.
The oldest is RTEMS. It orginally started life as a US Army project which was then made available as Open Source. It runs on most 32bit and some 16 and 64bit embedded processors including the m68k, ColdFire, x86, PowerPC, MIPS, Hitachi SH, Sparc, etc. It has a flexible API, supports POSIX apps, has a TCP/IP stack and all of the usual features. The next release (due soon) will bring the joys of filesystems, embedded web servers, ITRON API support and other useful features. The licence is GPL + a simple exception (like libio or libstdc++ in gcc). More info can be had at http://www.rtems.com/ . Full blown commercial support is available from the main developers if required.
The new kid on the block is eCos from Cygnus/Red Hat (or should that be Cyghat;). This is aimed at smaller systems than RTEMS and is highly configurable. It is supported on fewer processors than RTEMS but this is mainly due to it's youth. The licence is similar to the RTEMS one but is not based on the GPL. For more info see http://sourceware.cygnus.com . Again, full blown commercial support is available.
Another newcomer is uC/Linux. This is a version of Linux suitable for use on MMUless processors like the m68k/ColdFire series and the i960. Has most of the features that we know and love(?) from it's larger cousin. Great for information appliance like devices, less so for truely embedded or real time applications.
Of course there are other choices if you have more powerful hardware... I think that both xBSD and Linux have realtime extensions and they can both run on a wide variety of processors.
GPRS extends the existing GSM protocol to give circa 140kbps "always on" data links. This arrives next year in Europe (about 2033 in the US).
UMTS will offer bucket loads of bandwidth - I forget how much..somewhere between 2MB and 9MB I think. This will take a bit longer to appear as it requires a completely new network infrastructure and set of frequencies.
Unfortunately our friends in the US don't seem to like these technologies.... A strong attack of NIH syndrome I should say.;)
BTW, for Europe in the previous comment read Rest-of-the-World-except-USA.
The views of us Scots (or the Welsh or Northern Irish) seem to be diverging from the English (or more specifically the Southern English). Perhaps if we were an independant state within Europe we might make a few more rational decisions when it comes to stuff like cryptography...
The really cool thing about Pathfinder was the hack they did to patch the statically linked operating system (vxWorks - yukk, they should have used RTEMS) to fix it's priority inversion problem...on Mars!
See here and here. What's really funny is that this problem was reported by somebody from Microsoft - problably the least Real Time aware company (after Sun and Oracle) on the planet.
Slashdot Mirror
I know that the audience for Tom HW Guide, etc is primiarily interested in general purpose programs and games. It would be nice if there was a hardware review site (or paper mag) that was targetted towards the technical user a bit more. Even CAD mags manage to carry the odd HW review in them but have you ever seen a software publication reviewing software development hardware?
;)
As for Q3A... I'm too busy waiting for my compile to finish
Having read a couple of Spitfire (I can't bear to say Duron) and Thunderbird reviews I am struck by just how irrelevant the performance figures are to me. Like a lot of Slashdot readers I do a *lot* of software development and spend forever watching gcc, msvc and Delphi chew processor cycles. I'd give anything to find out the most effective platform for what I do.... how quickly Word loads or Q3A runs is not likely to be representative. The few benchmarks that these sites run that do involve a compiler (some of the Spec* tests use gcc and the ZD Content Creation bm uses msvc AFAIK) never quote the results separately from the whizzy 3D piccie software.
Wouldn't it be great if we could get hardware reviews of setups that software developers are likely to want. Is the Thunderbird really quicker than the Coppermine and Spitfire for building Mozilla on Linux(or Windows)? Is it worth paying for SCSI or is that PC266DDR SDRAM what we should hold out for?
>If you take all of this out, you pretty much
;)
>have a RISC chip. And you'd still be compatible
>with 95% of the code that runs on the Pentium II
>and III. I expect we'll be seeing this kind of
>thing soom from either Intel or AMD.
This is exactly what Motorola did a couple of years ago with the ColdFire which is an m68k chip with all of the naff or complex instructions stipped out. They call it Variable Length RISC because it has a reduced instruction set (which runs a lot quicker) but still retains the compact opcodes of the m68k family. Getting rid of the junk means that a (non-superscalar) ColdFire is a *LOT* faster clock for clock even when compared with the superscalar 68060.
One feature which might be of interest from an x86 legacy code standpoint is that you can run m68k on a ColdFire with the aid of an efficient emulation library that traps illegal opcode exceptions and emulates the instructions. If you pick your instruction carefully the hit from this _should_ be minimal.
Of course if Motorola had done to the ColdFire/m68k what AMD/Intel have done to the x86 the PowerPC would be extinct.... well we can dream
See the URL above for more info.
Yeah right.
The pigs are fueled, watered and ready for take off.
Whilst what you say is all true. To achieve equal functionality with Linux rather than QNX or RTEMS will require a lot of bloat. Linux is bloated. I've spent the last couple of months working on a contract using ucCLinux which is the most pared down version yet. Trust me, Linux is bloated for deeply embedded systems like the iopener.
In many respect Linux is like Window CE (except that CE has better realtime response). All hype, lots of eager followers and very little performance. The only thing it has going for it is that it is Open Source. Keep it on the goddamn desktop where it belongs! (and does a very good job thankyou)
>1. a linux/gui combon in 8mb of flash vs the
> or more likely <a href="http://www.rtems.com">RTEMS</a> running <a href="http://microwindows.censoft.com/">Microwindo ws</a>. This would possibly leave enough room in the flash for offline message stores and the like if required.
>10mb that QNX uses
This is deeply unlikely...
Linux is just too fat. Getting a version of text mode linux with out any gui into 8MB of flash it is tough enough (the IOpener doesn't have a lot of ram so compressed RAM disks are going to have to be damn small). Getting a halfway decent lightweight web browser and micro GUI to sit ontop of that is also more than a little difficult.
A more credible solution would be to consider one of the Open Source Real Time embedded operating systems like <a href="http://sourceware.cygnus.com/ecos/">eCos</a
Dave
Thanks for injecting a dose of normality. I was getting worried that this was going to turn into a "It made my girlfriend pregnant just because she looked at it" stampede panic ;)
I2O is pretty naff from a software standpoint. The i960 that is used for the IO processor (hey they used to use Z80s for this!) runs vxWorks. Couldn't they have used an open source "alternative" like RTEMS?
At the moment Mozilla is too tied to the Javascript engine and not enough of the interfaces are accessable through XPIDL generated interfaces which makes wiring up another scripting engine difficult.
This is all set to change however but not till after the first release. When all the relevant interfaces are represented(or representable) in XPIDL it should happen...this will also make embedding the browser much easier too.
Thank you for pointing out the differences between the Scottish Law system and the English/US/Austrialian law system. Not a lot of people know that ;)
There is an interesting point in here though... Demon used to be an English company but was bought a while back by Scottish Power for their Scottish Telecom subsidiary which is now known as "Thus(tm)" (Nearly as stupid as Inprise). Of course Demon didn't move their NOCs up to Scotland (too damn expensive for little gain) but in a case like this would the defamation claim be held under English Law (because the servers & claimant were in England) or under Scottish Law because the company was Scottish?
Or maybe it's all irrelevant because it happened before the buy out?
The problem with Real Time response has nothing to do with writing the thing in assembler. You can write buggy non-deterministic code in any language and in many ways "big computer" assembler encourages this. Most true real time operating systems these days are written in C (e.g. RTEMS or eCos - both are open source examples).
The big problem (OS/kernel level patches aside) is, I suspect, more the _way_ Linux applications are generally built. Most "big computer" (i.e. Windows, Linux, etc) programmers don't understand how to build deterministic real-time code. From a conventional app standpoint you would never contemplate pre-allocating all dynamic memory structures, tasks, etc but this is absoutely necessary to provide the necessary deterministic response required of a real-time program. Most app developers will choose the solution that provides the highest speed for the common case - real time systems often take a performance hit on the common cases to ensure that *all* cases meet the deadline. Designing a multi-threaded application to be responsive, not suffer priority inversion, etc,etc is tough.
One of the good things to note though is that there is a lot of Open Source real-time work going on out there with RTEMS, eCos and RTLinux providing a sound platform for developers to learn and use real-time techniques.
You could always have a national health service like more civilised parts of the world....you know where medical care is given on the basis of need rather than what type of job you have.
Sorry. That's a bit harsh but, (like GSM mobile phones), true.
NT (or more correctly NTFS) has had hardlink support for ages. This was needed for it's "POSIX" subsystem (which is now decrepit). This feature is used heavily by the Cygwin project(http://sourceware.cygnus.com/cygwin/) to emulate unix hard links.
;)
;)
There is no equivalent of a symlink in NT though. Shortcuts are nothing like symlinks as people have pointed out
You can use sym and hard links within Cygwin but it emulates the symlinks by creating a file with a pointer to the correct location. Everything works as planned if you use Cygwin hosted tools (bash, cp, mv, etc) but it gets horribly confused when you move symlinked things arond with explorer
Is that the same guy who used to work for Netscape on Mozilla...?
;)
If so there's hope for the project
Hmm... Given the existence of GCC, maybe they will open source or drop the compiler, and sell the IDE only instead.
;)
I hope not. The Borland compiler has a lot of advantages, the main one being speed. The Delphi 4 compiler will build my 100k line application from scratch in around 60sec on a PII-233+192MB RAM. An equivalent sized C application can take ~10mins (under Linux - much much more under Windows/Cygwin)....
GCC however is highly portable and can target many platforms and processors. Which is really neat....but you don't need (or want) an IDE to do that. Autoconf/Automake is your friend
There are currently two Open Source pascal projects:
;) so can target virtually any platform that GNU C can and is highly optimising. Supports a wide variety of Pascal standards. Somewhat compliant with Borland Pascal.
;). Both compilers are cross-platform and cross-processor which is a Good Thing(tm).
- Free Pascal: Written in itself, has a lot of extensions over "standard" Pascal which bring it _close_ to Borland Pascal. Available for a few non-x86 platforms.
- GNU Pascal: Written as a language front-end to GCC(GNU Compiler Collection
Neither of these compilers are in the same league as Borland Delphi. They are both staggeringly slow compared with the Borland compilers (OK, I can forgive GNU Pascal as it shares exactly the same back end as GCC). Neither compiler has adopted many Delphi-isms - which is good if you want a Borland Pascal look-a-like but lousy if you have 100k+ lines of Delphi (like me
When I looked at trying to improve these projects back in 96/97 the developers seemed less than enthusiastic about adopting Delphi constructs... YMMV.
Object Pascal achieves what you request.
;)
- It removes the little used features and arcane characters.
- Has excellent, easy to use, _reliable_ exception handling.
- Has *strong* typing for improved productivity.
- Compiles quickly to code of comparable quality to C++.
Unfortunately the language has been hijacked by Borland/Inprise with it's proprietary (but excellent) implementation. Also no sane programmer would use Pascal because it makes your code easy to read and of course, as far as jobs are concerned, obsurity = security
Let the holy war commence...
Having read through the stuff that this guy has figured out it looks like there is way too much junk in there.
The cartridge interface is pretty much entirely hooked up to the RCP. Who knows what all is in that chip... If it were me I would put a small amount of ROM in there with an unmodifiable boot monitor that checked the validity of the cartridge. I would also have a nasty bus interface to the cartridge to make it a bit tougher on Mr Joe Hacker.
It's a shame that they didn't put the bus of the VR4300i on the cartridge slot with ~CSBOOT(or whatever that is in MIPS-speak)... Then you'd just need to hookup a bit of FLASH to run the OS of your choice. A number of OpenSource OSs would run on an N64: RTEMS, eCos and I guess Linux. Linux would be the least favoured option. This is because 4MB is not a heck of a lot for a 64bit MIPS machine running bloatware (compared to RTEMS or eCos) like Linux.
Fo more info on RTEMS see http://www.rtems.com/
For more info on eCos see http://sourceware.cygnus.com/
I agree....some even have a series of Broadway Musicals as well ;)
:(
It's a real shame because there were quite a few nominations for _genuine_ unsung heros who have really made a difference to the project they worked on. I guess that this is the nature of the beast though. If they are unsung heros then people are hardly going to recognise them or their work.....
Please read the thread:
"user-agent strings" by Judson Valeski on netscape.public.mozilla.netlib for some possible solutions.
£24k for a graduate (that's with a Masters degree for my American viewers) is pretty good.
I wouldn't mind getting paid £24k and it's been a loooong time since I graduated.
There are many well known Open Source OSes that are suitable for embedded systems.
;). This is aimed at smaller systems than RTEMS and is highly configurable. It is supported on fewer processors than RTEMS but this is mainly due to it's youth. The licence is similar to the RTEMS one but is not based on the GPL. For more info see http://sourceware.cygnus.com . Again, full blown commercial support is available.
The oldest is RTEMS. It orginally started life as a US Army project which was then made available as Open Source. It runs on most 32bit and some 16 and 64bit embedded processors including the m68k, ColdFire, x86, PowerPC, MIPS, Hitachi SH, Sparc, etc. It has a flexible API, supports POSIX apps, has a TCP/IP stack and all of the usual features. The next release (due soon) will bring the joys of filesystems, embedded web servers, ITRON API support and other useful features. The licence is GPL + a simple exception (like libio or libstdc++ in gcc). More info can be had at http://www.rtems.com/ . Full blown commercial support is available from the main developers if required.
The new kid on the block is eCos from Cygnus/Red Hat (or should that be Cyghat
Another newcomer is uC/Linux. This is a version of Linux suitable for use on MMUless processors like the m68k/ColdFire series and the i960. Has most of the features that we know and love(?) from it's larger cousin. Great for information appliance like devices, less so for truely embedded or real time applications.
Of course there are other choices if you have more powerful hardware... I think that both xBSD and Linux have realtime extensions and they can both run on a wide variety of processors.
GPRS extends the existing GSM protocol to give circa 140kbps "always on" data links. This arrives next year in Europe (about 2033 in the US).
;)
UMTS will offer bucket loads of bandwidth - I forget how much..somewhere between 2MB and 9MB I think. This will take a bit longer to appear as it requires a completely new network infrastructure and set of frequencies.
Unfortunately our friends in the US don't seem to like these technologies.... A strong attack of NIH syndrome I should say.
BTW, for Europe in the previous comment read Rest-of-the-World-except-USA.
I'll second that.
The views of us Scots (or the Welsh or Northern Irish) seem to be diverging from the English (or more specifically the Southern English). Perhaps if we were an independant state within Europe we might make a few more rational decisions when it comes to stuff like cryptography...
The really cool thing about Pathfinder was the hack they did to patch the statically linked operating system (vxWorks - yukk, they should have used RTEMS) to fix it's priority inversion problem...on Mars!
See here and here. What's really funny is that this problem was reported by somebody from Microsoft - problably the least Real Time aware company (after Sun and Oracle) on the planet.
Maybe this might convince you slow coach Americans that adopting DAB is a Good Thing(tm)....
.'. DAB much be good right?
DAB uses MP3