Intel details future Larrabee graphics chip
in [Design]
|
Prev: LM3478 design gets insanely hot
Next: 89C51ED2
From: Rob Warnock on 11 Aug 2008 08:22 Guy Macon <http://www.GuyMacon.com/> wrote: +--------------- | 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. +--------------- Yup! In the early days of DCA[1], the EEPROMs we used in our remote concentrators were still *very* expensive, and there were several times where if we'd had to send out replacements to all the units in the field[2] we simply wouldn't have been able to make the next payroll!! ;-} So we *had* to make very, very sure that we didn't have any bugs. And, yes, we were writing exclusively in PDP-8 & Z-80 assembler.[3] -Rob [1] Digital Communications Associates in Atlanta, not the ".gov" one. [2] You have to send out the new ones before anyone will stop using the production equipment long enough to send you back the old ones for re-programming! [3] Well, we actually wrote BLISS-like pseudo-code (which got left in the comments) and then "hand-compiled" it to assembler. But both the BLISS pseudo-code and the assembler got line-by-line reviews by multiple people. Expensive, but quite reliable. ----- Rob Warnock <rpw3(a)rpw3.org> 627 26th Avenue <URL:http://rpw3.org/> San Mateo, CA 94403 (650)572-2607
From: John Larkin on 11 Aug 2008 10:34 On Mon, 11 Aug 2008 09:09:11 +0000, Guy Macon <http://www.GuyMacon.com/> wrote: > > > >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." Assembly? You don't program musical greeting cards and blinking sneakers in Python? John
From: John Larkin on 11 Aug 2008 10:45 On Mon, 11 Aug 2008 10:11:23 +0300, Kim Enkovaara <kim.enkovaara(a)iki.fi> wrote: >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. Never? Every FPGA on the planet has bugs? >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 For some reason, our shipped products rarely have bugs in FPGAs or in embedded code. But development-time bugs are far fewer in FPGAs as compared to uP code. One recent product has about 7K lines of VHDL and 7K lines of assembly, and I'd estimate the initial-coding bug level to be 10 or maybe 20:1 in favor of the VHDL. Most of the test instruments I've bought lately seem to have superb hardware and flakey firmware. I've got a small software project going now to write a new material control/BOM/parts database system. The way I've found to keep the bugs under reasonable control is to use one programmer, one programmer supervisor, and four testers. John
From: Jan Panteltje on 11 Aug 2008 11:00 On a sunny day (Mon, 11 Aug 2008 07:45:08 -0700) it happened John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in <iij0a4ho0867ufr82loiq6epj3b23u8svr(a)4ax.com>: >I've got a small software project going now to write a new material >control/BOM/parts database system. The way I've found to keep the bugs >under reasonable control is to use one programmer, one programmer >supervisor, and four testers. > >John postgreSQL with phpPgAdmin as frontend here, web based. What bugs? Yes the bugs in my SQL :-)
From: John Larkin on 11 Aug 2008 11:45
On Mon, 11 Aug 2008 12:17:07 +0100, Martin Brown <|||newspam|||@nezumi.demon.co.uk> wrote: >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. XP should be fairly stable by now. Its code base been continuously debugged and repaired for about 15 years now. Probably 50K bugs have been fixed. >>> >>>> 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. So what do you do with all those cores? Let N-1 of them sit idle, and multitask/context switch/swap like mad one the one you do use? >> >> 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. No, the new new thing is hypervisors and virtualization. Programmers never want to simplify, because that's no fun. They want to abstract, to pile complexity on top of the complexity they've grown bored of. A microkernel, written by one programmer, that runs on one CPU, that's fully documented and never breaks, is indeed naive. It's naive because the current computing culture would ridicule it as being insufficiently clever. > >>> 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). Reducing crashes is actually the easy part. Security is a tougher problem. Windows is the worst, but AppleOS and Linux have security problems, too. This should simply not be possible. > >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. I vote to simplify. What do you want to do? John |