API Design
in [General Programming]
|
Prev: Water plant design | Design Build | Water plant construction
Next: Two programs with same logic
From: Chris McDonald on 21 Dec 2009 16:03 "BGB / cr88192" <cr88192(a)hotmail.com> writes: >the original PDP's were not exactly overflowing with RAM, and this is where >GC got started... I think you'll find that the history of GC *easily* predates the PDP series. Start here: http://www.cs.kent.ac.uk/people/staff/rej/gcbib/gcbibA.html -- Chris.
From: Malcolm McLean on 21 Dec 2009 16:14 "Marco" <prenom_nomus(a)yahoo.com> wrote in message >I respectfully disagree that this belongs in the C language. The C >language is essentially portable assembly language and should remain >that way. Of course JVMs and so forth are usually written in C. I >don't want featuritis in the C language. Jacob please create a new >language if needed. > So the new language uses, for example, <- for assignment. Why? Well ypu could argue that this would have been a better choice for C. But the main reason is to make it a different language for C. It turns into a nightmare. I only rarely use Perl as a sort of super shell language. I regularly find myself looking in the book to find out how to perform simple operations like cutting strings at a certain index, or to continue a loop (I think it's "next"). C with knobs and whistles at least fucntions as you would expect C to.
From: Malcolm McLean on 21 Dec 2009 16:19 "jacob navia" <jacob(a)nospam.org> wrote in message > > Sure, you have 16 BYTES of memory and you want C to run in that? > > Sorry but that is completely out of the question. > If you do so , then I'd guess that effectively you are using the C compiler as an assembler. Probably functions and non-const pointers are banned, and there's some overlay syntax so ypu can use different identifiers for the same physical memory.
From: robertwessel2 on 21 Dec 2009 16:30 On Dec 21, 12:05 pm, "BGB / cr88192" <cr88...(a)hotmail.com> wrote: > "Ian Collins" <ian-n...(a)hotmail.com> wrote in message > > Some yes, but I don't think you appreciate how many small (8 and 16bit) > > embedded processors are still in use in new products today. > > probably more are 32-bits though I think. Of the approximately 10 billion CPUs produced annually, probably about 15% are 32 bit or larger (the generally available estimates run about 10-20%, the "good" numbers are in expensive reports). 8 bitters hold about a 50% market share (by volume). Desktop/server class processors are about .2% (two-tenths of a percent) of the market by volume, but about half by value.
From: bartc on 21 Dec 2009 19:21
robertwessel2(a)yahoo.com wrote: > On Dec 21, 12:05 pm, "BGB / cr88192" <cr88...(a)hotmail.com> wrote: >> "Ian Collins" <ian-n...(a)hotmail.com> wrote in message >>> Some yes, but I don't think you appreciate how many small (8 and >>> 16bit) embedded processors are still in use in new products today. >> >> probably more are 32-bits though I think. > > > Of the approximately 10 billion CPUs produced annually, probably about > 15% are 32 bit or larger (the generally available estimates run about > 10-20%, the "good" numbers are in expensive reports). 8 bitters hold > about a 50% market share (by volume). Desktop/server class processors > are about .2% (two-tenths of a percent) of the market by volume, but > about half by value. So there are a large number of very cheap and very simple processors around. Someone decides to adapt the C language to those, instead of creating a custom language (and when you get rid of all the baggage, and concentrate on the one target, that's not so difficult). Is programming in a considerably cutdown (and perhaps specially customised) C language, actually programming in C, or in something that just looks like C, complete with curly braces, semicolons and funny type declarations? I think by using just the one designation for the language, instead of splitting it up, it is made out to be as widespread as some people are claiming. -- Bartc |