Intel details future Larrabee graphics chip
in [Design]
|
Prev: LM3478 design gets insanely hot
Next: 89C51ED2
From: Jan Panteltje on 10 Aug 2008 15:52 On a sunny day (Sun, 10 Aug 2008 12:22:17 -0700) it happened John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in <gdfu94p2jcn004o6mle4djnuaoslkd0vp7(a)4ax.com>: >>Stating that more cores will improve _reliability_ >>(in the widest sense of the word) as you seem to >>(at least that is what I understand from your postings), >>puts the burden of proof on you. >> >>You call software bad, yet you claim your own small asm programs are perfect, >>this makes one suspicious. > >Small programs written by one person can be perfect, and often are. So >why not have the OS kernel be small, and written by one person? QNX has just made their sources public, you still need a license for commercial use though. Are you thinking that way? In the eighties I worked with somebody who really liked QNX, I was into Unix. Unix in the form of Linux solves a lot of programming problems, but brought the real-time problem of task switching breaking some MSDOS like apps. So in a way required more hardware. >Why waste X-prizes on solar cars and suborbital tourism? How about... > >$10 million for a firm specification of a multiple-CPU OS architecture >based on a nanokernel design. > >Another $10M for public-domain code that implements that kernel. > >A final $10M for a working OS using the above. > >For a mere $30 million, about 1/5 of what the first release of what NT >cost, we could change the world. > >(I think Vista is an attempt at a smaller kernel, but it pays a big >price in overhead.) Why spend all those millions, we _have_ Linux, it works, and - it is mostly written in C -, and because of that relatively easy portable to many platforms.
From: Kim Enkovaara on 11 Aug 2008 03:11 John Larkin wrote: > than the older ones. In products with hardware, HDL-based logic, and > firmware, it's nearly always the firmware that's full of bugs. If > engineers can write bug-free VHDL, which they usually do, why can't > programmers write bug-free C, which they practically never do? There is no such thing as bug free HDL. The bug density is just usually lower especially in ASICs. The main reason for that is more thorough testing of the code, because respins of the chips is slow and expensive. In FPGAs when you can always do an update the bug densities are much higher in the beginning. --Kim
From: Kim Enkovaara on 11 Aug 2008 03:20 John Larkin wrote: >> Re-writing your code in ASM for each new platform is asking for bugs, >> so C is an universal solution. > > Changing "platforms" in an embedded system is such a hassle that the > code is a fraction of the effort. It's rarely done. At least in the high-end of the embedded systems processor updates and model changes are quite frequent. The lifetimes of processors and their peripherials (especially DRAM memories) is becoming shorter all the time. The code has to be portable and easily adaptable to different platforms. > And C is not portable in embedded systems. Assuming it is is begging > for bugs. C is very portable in embedded systems as far as I have seen. Some very minimal processors have weird compilers, but the bigger processors usually have gcc support, and also the commercial compilers support the C same way as gcc. >> Especially for more complex programs. > > Don't do that. High-end embedded systems can easily contain 10Mloc of code, and that amount is needed to support all the required features. --Kim
From: Guy Macon on 11 Aug 2008 05:09 Kim Enkovaara wrote: > >John Larkin wrote: > >>> Re-writing your code in ASM for each new platform is asking for bugs, >>> so C is an universal solution. >> >> Changing "platforms" in an embedded system is such a hassle that the >> code is a fraction of the effort. It's rarely done. > >At least in the high-end of the embedded systems processor updates and >model changes are quite frequent. The lifetimes of processors >and their peripherials (especially DRAM memories) is becoming shorter >all the time. The code has to be portable and easily adaptable to >different platforms. And at the very low end, changes to completey different processors are also very common. If someone comes up with a micro that costs 8.4 cents and replaces a part that costs 8.5 cents, that's a saving of $16,800 per week at a production rate of 100,000 units per hour. After a while you get the attitude of "ho hum, another assembly language instruction set." As for "asking for bugs", I find that working with masked rom parts with a big setup fee and a minimum order of 10,000 parts clarifies the mind quite nicely. -- Guy Macon <http://www.GuyMacon.com/>
From: Martin Brown on 11 Aug 2008 07:17
John Larkin wrote: > On Fri, 08 Aug 2008 18:12:14 +0100, Martin Brown > <|||newspam|||@nezumi.demon.co.uk> wrote: > >> John Larkin wrote: >>> So what do you think OS's will look like 10 years from now, when even >>> home computers run on chips with 100's of cores? Still one gigantic >>> VMS/Mach/NT descendent running on one CPU, thrashing and piping >> A lot of IO is concentrated by the bridge hardware these days. And >> serial ports have had moderate to large FIFOs for about a decade. >> >> XP runs quite happily on my dual core. Vista runs less happily on my new >> Toshiba portable and I will never recommend using it to anyone. >> >>> And those other cores stay idle unless you play a game? >> I can see a case for cores allocated to processes with highest demand >> for resources, but I do not believe it makes any sense to have one >> thread per core with a properly designed secure operating system. > > Umm, excuse me, what do those words mean, "properly designed secure > operating system" ? They mean one that uses the security features properly that already exist in many CPU architectures (and on properly designed hardware that is not vulnerable to tricks to obtain engineering diagnostic mode or executing bogus partially decoded non-existent instructions to trap and claim ring0 status). But alas the hardware isn't perfect either eg. http://msowww.anu.edu.au/~peterson/pentium_lock.htm > > That's what my wife asked me once when I was stupid enough to use the > phrase "too much garlic." > > >> In exactly the same sense as you claim for your magical hardware >> architecture a properly designed secure OS would be well secure. > > There's nothing magical about lots of cores. Everybody is doing it. Everybody is doing lots of cores, but very few are advocating the wasteful and naive usage strategy that you seem to want. >> I could be persuaded that Mickeysoft leave 'Doze vulnerable to avoid >> putting the AV people out of business (that would be anti-competitive). > > As James says, don't assume malice when incompetance will do. I suspect you are right. But the conspiracy theory is more fun! >>> Things will never change? We'll always use 1980's OS architectures? >> Sadly I suspect that might well be the case until some compelling reason >> to change comes along. Do you not remember how long the delay was before >> there were 32bit consumer grade OS's for the early 386 PCs? > > What may well happen is that, once hundred-core CPUs are out in the > wild, some small group of Linix kernal jocks will spin a version that > *can* have file systems, drivers, stacks, and apps assignable to > various CPUs. Then it would just be a configuration thing to assign > one cpu to run just the OS. That would be dynamite for server apps. > > Then Microsoft will scramble to catch up, as usual. A decent OS properly configured doesn't crash all that often (even when doing software development). My XP box crashes maybe once every few months, my old Win98 box slightly more often. These days it needs a good kick to free the disk stiction if I switch it on. Win95 crashed at least daily. But NT3.51 was a gem, and my OS/2 box only ever crashed about once a year (perhaps I remember them through slightly rose tinted glasses). My new Vista on a Toshiba portable crashes (or rather its keyboard and on/off switch locks up) every time I leave leave it on and unattended for long enough that the power managment engages. Sadly it doesn't have a reset switch (my bad). I would not use Vista from choice but customers want me to :( I do agree with you that consumer OS's have become far too big and clunky with bloatware and not enough emphasis on security. Where we differ is on what to do about it. Regards, Martin Brown ** Posted from http://www.teranews.com ** |