Intel details future Larrabee graphics chip
in [Design]
|
Prev: LM3478 design gets insanely hot
Next: 89C51ED2
From: Wilco Dijkstra on 12 Aug 2008 18:47 "Nick Maclaren" <nmm1(a)cus.cam.ac.uk> wrote in message news:g7t0um$9jm$1(a)gemini.csx.cam.ac.uk... > > In article <tSmok.154054$dz3.98710(a)newsfe20.ams2>, > "Wilco Dijkstra" <Wilco.removethisDijkstra(a)ntlworld.com> writes: > |> > |> > At last something that we can agree on. Too much software is not properly designed. Modern compilers these days > have a > |> > fair amount of static testing built in, but nothing like enough to solve the problem of below average coders and > poor > |> > or no specifications or design documents. > |> > > |> > It will draw fire from the C is always wonderful crowd but I expect you can live with that. And it isn't strictly > the > |> > C language that is at fault. There is plenty of good well documented software written in C. > |> > |> Exactly. A poor programmer is going to be a poor programmer no matter > |> what language they use. It's always fun to see how people believe that > |> so called "safe" languages are really a lot "safer". The bugs just move > |> elsewhere. For example garbage collection solves various pointer problems > |> that inexperienced programmers make. However it creates a whole new > |> set of problems. Or the runtime system or libraries are much bigger and so > |> contain their own set of bugs on each platform etc. > > There are at least two major classes of bug where it is false, and > C does especially badly: > > 1) Bugs introduced by an inconsistent, ambiguous or unreasonable > standard. It's certainly true the C standard is one of the worst specified. However most compiler writers agree about the major omissions and platforms have ABIs that specify everything else needed for binary compatibility (that includes features like volatile, bitfield details etc). So things are not as bad in reality. > 2) Bugs which are provably easy to detect (e.g. array bound or > arithmetic overflow). That is an argument about what exactly should be part of a language and what should be part of the libraries. Automatic strings, checked arrays and overflow arithmetic are all things that are/can be supported easily in C/C++. There are certainly advantages of having this built into the language, however there are drawbacks too. Wilco
From: JosephKK on 12 Aug 2008 22:41 On Sat, 09 Aug 2008 09:28:17 -0700, John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >On Sat, 09 Aug 2008 09:15:28 -0700, JosephKK <quiettechblue(a)yahoo.com> >wrote: > >>On Fri, 08 Aug 2008 07:40:53 -0700, John Larkin >><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >> >>>On Fri, 08 Aug 2008 11:30:04 GMT, Jan Panteltje >>><pNaonStpealmtje(a)yahoo.com> wrote: >>> >>>>On a sunny day (Fri, 08 Aug 2008 13:02:15 +0200) it happened Bernd Paysan >>>><bernd.paysan(a)gmx.de> wrote in <nmltm5-4hq.ln1(a)annette.zetex.de>: >>>> >>>>>Nick Maclaren wrote: >>>>>> In theory, the kernel doesn't have to do I/O or networking, but >>>>>> have you ever used a system where they were outside it? I have. >>>>> >>>>>Actually, doing I/O or networking in a "main" CPU is waste of resources. Any >>>>>sane architecture (CDC 6600, mainframes) has a bunch of multi-threaded IO >>>>>processors, which you program so that the main CPU has little effort to >>>>>deal with IO. >>>>> >>>>>This works well even when you do virtualization. The main CPU sends a >>>>>pointer to an IO processor program ("high-level abstraction", not the >>>>>device driver details) to the IO processor, which in turn runs the device >>>>>driver to get the data in or out. In a VM, the VM monitor has to >>>>>sanity-check the command, maybe rewrites it ("don't write to track 3 of >>>>>disk 5, write it to the 16 sectors starting at sector 8819834 in disk 1, >>>>>which is where the virtual volume of this VM sits"). >>>>> >>>>>The fact that in PCs the main CPU is doing IO (even down to the level of >>>>>writing to individual IO ports) is a consequence of saving CPUs - no money >>>>>for an IO processor, the 8088 can do that itself just fine. Why we'll soon >>>>>have 32 x86 cores, but still no IO processor is beyond what I can >>>>>understand. >>>>> >>>>>Basically all IO in a modern PC is sending fixed- or variable-sized packets >>>>>over some sort of network - via SATA/SCSI, via USB, Firewire, or Ethernet, >>>>>etc. >>>> >>>>Do not forget, since the days of 8088, and maybe CPUs running at about 13 MHz, >>>>we now run at 3.4 GHz, 3400 / 13 = 261 x faster. >>>>Also even faster because of better architectures. >>>>This leaves plenty of time for a CPU to do normal IO. >>>>And in fact the IO has been hardware supported always. >>>>For example, although you can poll a serial port bit by bit, there is a hardware shift register, >>>>hardware FIFO too. >>>>Although you can construct sectors for a floppy in software bit by bit, there is a floppy controller >>>>with write pre-compensation etc.. all in hardware. >>>>Although you could do graphics there is a graphics card with hardware acceleration. >>>>the first 2 are included in the chip set, maybe the graphics too. >>>>The same thing for Ethernet, it is a dedicated chip, or included in the chip set, >>>>taking the place of your 'IO processor'. >>>>Same thing for hard disks, and those may even have on board encryption, all you >>>>have to do is specify a sector number and send the sector data. >>>> >>>>So.. no real need for a separate IO processor, in fact you likely find a processor >>>>in all that dedicated hardware, or maybe a FPGA. >>>> >>> >>>That's the IBM "channel controller" concept: add complexm specialized >>>dma-based i/o controllers to take the load off the CPU. But if you >>>have hundreds of CPU's, the strategy changes. >>> >>>John >> >>Why would it? The design could also use hundreds or thousands of >>dedicated I/O controllers. If you want to talk about real >>bottlenecks look at memory and data bus limitations. >> > >A lot of hardware sorts of stuff, like tcp/ip stack accelerators, >coule be done in a dedicated cpu. Sort of like using a PIC to blink an >LED. Part of the channel-controller thing was driven by mot wanting to >burden an expensive CPU with scut work and interrupts and context >switching overhead. All that stops mattering when cpu's are free. Of >course, disk controllers and graphics processors would still be >needed, but simpler ones and fewer of them. > >Multicore is especially interesting for embedded systems, where there >are likely a modest number of processes and no dynamic add/drop of >tasks. The most critical ones, like an important servo loop, could be >dedicated and brutally simple. Freescale is already going multicore on >embedded chips, and I think others are, too. The RTOS boys are *not* >going to like this. > >John > Between that and the tricks you can do with FPGAs, most certainly.
From: JosephKK on 12 Aug 2008 23:36 On Tue, 12 Aug 2008 12:00:43 +0100, Martin Brown <|||newspam|||@nezumi.demon.co.uk> wrote: >Guy Macon wrote: >> John Larkin wrote: >>> Guy Macon <http://www.GuyMacon.com/> wrote: >>> >>>> Kim Enkovaara wrote: >>>>> 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? >> >> Actually, I use the BEST programming language. >> >> BEST is a programming language that I developed >> to answer the frequently asked question "Which >> programming language is best?" once and for all. >> >> BEST is a Befunge-93[2] pseudocompiler written in >> Malborge[3][6] with library calls to routines written >> in Microsoft[4] Visual BogusFORTH+++[7] (!Kung edition)[9] >> that invoke various trinary functions written in[5] >> Reverse Polish Whitespace (for clarity).[1] > >You will just love Unlambda then... >http://www.madore.org/~david/programs/unlambda/#what_is >;-) > >Simplified, Turing complete but devlishly hard to do anything in. > >Regards, >Martin Brown >** Posted from http://www.teranews.com ** Sounds similar to APL.
From: JosephKK on 12 Aug 2008 23:50 On Mon, 11 Aug 2008 10:05:01 -0700, John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >On Mon, 11 Aug 2008 15:00:39 GMT, Jan Panteltje ><pNaonStpealmtje(a)yahoo.com> wrote: > >>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 :-) > >A single database file, of fixed-length records, programmed in >PowerBasic, direct linear search to look things up. Fast as hell and >bulletproof. Only for fairly small numbers of records, not more than a few thousand. Try it with a modest database with say several million records. Big databases have several relational files with over a billion records. Data warehouses hit trillions of records in high tens of thousands of files and more. PowerBasic simply will not scale that high, nor will linear searches. On the other hand, for a few hundred records i have pressed word processing programs and spreadsheets into service and made them work nicely. > >We've been using my old DOS version for about 10 years, and never >corrupted or lost anything. The new windows-y version is a lot >spiffier, but has the same architecture. > >I may decide to sell it. It's designed specifically to manage >materials and BOMs for a small electronics manufacturer. We looked at >some commercial packages, Parts&Vendors and such, and decided to >upgrade our old DOS thing instead. Again, simplicity has its virtues. > >John
From: Terje Mathisen on 13 Aug 2008 02:00
Martin Brown wrote: > You will just love Unlambda then... > http://www.madore.org/~david/programs/unlambda/#what_is > ;-) > > Simplified, Turing complete but devlishly hard to do anything in. You, my friend, have sick mind. OTOH, the first macro language I came up with, for a terminal emulator/file transfer program, was only slightly more readable. :-( Terje -- - <Terje.Mathisen(a)hda.hydro.com> "almost all programming can be viewed as an exercise in caching" |