API Design
in [General Programming]
|
Prev: Water plant design | Design Build | Water plant construction
Next: Two programs with same logic
From: robertwessel2 on 22 Dec 2009 00:42 On Dec 21, 6:21 pm, "bartc" <ba...(a)freeuk.com> wrote: > robertwess...(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. Certainly for the smallest 8-bitters, the typical C compilers tend to omit a few features. Recursion, function pointers and floating point are often not implemented by default, although can often be enabled optionally (particularly float). But other than that, these mostly implement freestanding C as defined in the standard, and usually some subset of the standard library. Often there are processor specific extensions implemented, and often there are other odd (non-ANSI) default behaviors, which can often be modified. As an example, the Hi-Tech PIC10/12/16 compilers support only 24 and 32 bit (the IEEE in the later case) float formats, which doesn't quite meet the C requirements for a double, also only a limited form of recursion is supported, but pretty much everything else, including functions pointers, and much of the non-file-related standard library (no malloc either). Some limits do, of course occur, because of the very small sizes of these devices (there's only so much you can do with data structures when a PIC10F200* has 16 bytes of RAM and 256 instruction words - although considerably larger PICs exist - you can get PIC16s with up to 1KB of RAM and 16K** instructions), and often making good use of these devices requires the use of non-standard extensions (you often need to be aware of bank switching on the PICs, for example). The bigger 8-bitters, or more C-friendly ones (like the AVRs), and larger CPUs, tend to pretty much implement the whole freestanding ANSI (C90) spec. Remember that the bigger eight bitters are not really any smaller than the environment for which C was intended originally. The bigger PIC16s, which are still pretty small, have around 28KB*** of program memory and 1KB of RAM, compared to the original PDP-11s, which architecturally maxed out at 56KB**** of RAM (and the most of the original PDP-11/20s shipped with 8 or 16KB). So even on the smallest CPUs (well, ignoring the 4-bitters, and some other really, really, tiny ones), you have very much the C we all know, perhaps with a (surprisingly) few language limitations. There are, of course, practical limitations (which obviously do significantly impact code) imposed by the very small target environment. *While it wouldn't surprise me that most users of something the size of a PIC10F200 would program it in assembler, very many PICs are programmed in C. OTOH, the PIC10F200 *is* a valid target for at least some of the PIC C compilers. **Par-tay! ***16K 14-bit instruction words ****28K 16-bit words
From: robertwessel2 on 22 Dec 2009 00:54 On Dec 21, 10:59 pm, "BGB / cr88192" <cr88...(a)hotmail.com> wrote: > probably though, the amount of code produced is much smaller than the number > of units produced... > > for example, for an embedded system maybe the code is written and tweaked > some, and then maybe reused for many thousands of units sold?... Embedded systems run the gamut from very small (a few dozen lines of assembler) to very large (a couple of million lines of Ada on the F-22), and from few shipped units (starting at *1*) to tens of millions. Numerically, small and limited quantity designs vastly outnumber large and/or high volume designs, but you tend not to see them.
From: Squeamizh on 22 Dec 2009 02:04 On Dec 21, 6:19 pm, Thad Smith <ThadSm...(a)acm.org> wrote: > bartc wrote: > > 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? > > You decide. Most compilers now targetting small embedded processors > implement most of the C90 base language, plus the standard library minus > operating system and I/O calls. Localization features are usually > ignored. In that sense, they are between the C standalone and hosted > implementations. > > The compiler I am using for an 8-bit processor advertises, like many > embedded-target cross compilers, ANSI C compliance. Take that with a > grain of salt. What is meant by that is C90, not C99. That advice would be a lot more useful if you just stated the name of the compiler you're using.
From: BGB / cr88192 on 22 Dec 2009 02:35 <robertwessel2(a)yahoo.com> wrote in message news:f1239ae0-8ca9-49e0-9df5-060ef02eb435(a)m16g2000yqc.googlegroups.com... On Dec 21, 10:59 pm, "BGB / cr88192" <cr88...(a)hotmail.com> wrote: > probably though, the amount of code produced is much smaller than the > number > of units produced... > > for example, for an embedded system maybe the code is written and tweaked > some, and then maybe reused for many thousands of units sold?... <-- Embedded systems run the gamut from very small (a few dozen lines of assembler) to very large (a couple of million lines of Ada on the F-22), and from few shipped units (starting at *1*) to tens of millions. Numerically, small and limited quantity designs vastly outnumber large and/or high volume designs, but you tend not to see them. --> yep... (and I am off here having "fun" with an app written in large part in Python... as a service to anyone using said apps, people should probably refrain from using Python...). C has a lot of theoretical badness, and Python a lot of practical badness. with C, one can worry about memory leaks and bugginess. with Python, one can see the terrible performance and tendency to die resulting from random typecheck failures, uncaught exceptions due to trying to fetch a non-existant object field, ...
From: Flash Gordon on 22 Dec 2009 04:50
BGB / cr88192 wrote: > "Flash Gordon" <smap(a)spam.causeway.com> wrote in message > news:4a1507xvnc.ln2(a)news.flash-gordon.me.uk... >> BGB / cr88192 wrote: >>> "Ian Collins" <ian-news(a)hotmail.com> wrote in message >>> news:7p8sacFp4lU3(a)mid.individual.net... >>>> jacob navia wrote: >>>>> Ian Collins a �crit : >>>> Where's the quotes I asked for? >>>> >>>>>> FACT: The majority of new C development is for embedded applications >>>>> All new development done for the linux kernel and the thousands >>>>> of C systems in linux/Mac/Windows do not count. >>>> Sure they do, but they'll be outnumbered by other embedded developments. >>> FWIW, Quake 1 / 2 / 3 were in C. >>> >>> Doom 3, maybe C, but I haven't seen the source (the scripts though have >>> more of an OO style, so possibly C++ may have been used in Doom 3...). >>> >>> I also develop (mostly) in C, and generally write stuff which works on >>> plain old computers... >> There is a lot still done in C... > > yep, including in apps... A lot less there than there used to be. <snip> >>> similarly, the majority of code I end up encountering on the internet >>> tends to be in C (even despite the levels of hype and seeming popularity >>> of Java...). >> I don't think what you see on the internet is necessarily representative. >> There are some commercial areas where other languages have traditionally >> been used, and last time I was looking for a non-embedded SW development >> job most of the advertised jobs were not for C. >> > > I have noticed this as well... > > so, probably a lot more of the commercial SW field is non-C, but C still > holds dominance for open-source?... There is probably still a fair bit of open source done in C for a variety of reasons. There are a lot of library projects where they want to be usable from multiple languages, a lot of languages being written and extended etc. Also a lot of people historically would not have had easy access to compilers other than C compilers. <snip> >>>>> Your "Facts" aren't facts but assumptions of Mr Collins. >>>>> >>>>> And, by the way, if you are developing for an embedded processor, it is >>>>> probably better to use a GC and waste developper's time and risk bugs >>>>> with manual GC (malloc/free). >>>> For a lot of embedded targets (those with limited resources i.e most 8 >>>> and 16 bit machines), the best approach is a static design. >>> granted, but I still suspect "most of us" don't develop for embedded >>> systems of this sort... >> Maybe most of the people you know, but who do you think is writing all of >> the code for all of the embedded systems, such as the several embedded >> systems in your desktop PC? It's us SW developers, that's who. > > probably though, the amount of code produced is much smaller than the number > of units produced... > > for example, for an embedded system maybe the code is written and tweaked > some, and then maybe reused for many thousands of units sold?... A lot of designs sell rather more than thousands. However, new models are always being developed which will often require changes to the software. >>> for example, I suspect most developers probably still target actual >>> computers, and C is not exactly an unheard of language for usage in >>> typical computer-based apps... >> It's not unheard of, but neither is Cobol (and I know there is still Cobal >> code out there in real current commercial applications being actively >> developed and sold). I'm sure that Fortran is still in serious use too if >> you know where to look. I also know of significant bodies of commercial >> Java code, and I've used open source applications developed in C#. As an >> example of the type of thing Java is used for, I know that several >> commercial applications use Apache Tomcat to provide web services, with >> the application code written in Java running under Tomcat (which is >> written in Java). > > I suspect it is more common than Cobol or Fortran though, on account of not > to my knowledge having used apps which had been written in Fortran of > Cobol... how do you know what language a closed source program is written in? I only found out about some of the Cobol because I tripped over the way the licensing for the Cobol runtime was done in one case (I got an error that it could not find the license for the Cobol runtime). >>>>> Today's embedded processors are huge machines by yesterday's standards. >>>> 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. >> I have no evidence, but I would be surprised. I would be surprised if most >> of the processors in your car were not comparatively slow 8 and 16 bit >> processors, I know there are still a lot of such processors in use in >> military hardware (slow simple processors tend to cope with electrical >> noise better). I'll bet all of your remote controls have 8 bit (or >> smaller) processors since they don't need any more! > > possibly, although I don't personally own a car... The buses and trains you probably use will also have a number of embedded processors... <snip> >>>>> Only in 16 bits processors with a few kbytes of RAM you could be right. >>>> There's an awful lot of those in use today, you'll have several in your >>>> PC and probably several dozen in your home. >>> I think the bus controllers contain one of these, mostly as I guess I >>> read somewhere that some amount of the legacy hardware tends to be >>> emulated (via SW running in the bus controller). >> <snip> >> >> How about the processor in the keyboard? Or the processor in the NIC? The >> processor in the USB controller? The processor in the embedded USB hub? A >> number of these won't be emulated in the bus controller simply because it >> is cheaper to use the same components that are used in the cards you can >> plug in to your PC (or in the case of the keyboard because it is at the >> far end of a piece of wire). > > I meant what are actually "legacy" devices, IOW, the pieces of hardware that > typically only OS developers know about and any more have little use beyond > being vestigial (or operate underlying hardware notably different, such as a > PC speaker which makes noise on the sound card, That would not have been run by a processor in all probability. > keyboard controller which > operates via USB, You still *have* a keyboard controller, and it will *still* be in the keyboard (where it has been probably ever since the keyboard was connected to a computer by a wire). > USB-connected drives faking being connected via ATA when > the BIOS boots them, ...). If anything those will have *more* software in the external drive box. Also, they generally run SCSI over USB not ATA. Oh, and the software in the hard disk is also still probably being developed (the disks can normally report the software version, and you do find disks with different versions). The same goes for the software in the DVD drive. > I suspect "something" is going on here... There is a lot going on here. > NIC or USB are far too new, and almost invariably have actual electronics. Network cards are new? What planet have you been on? I was using networked computers in the 1980s! They were not new either! > however, I am not sure which exact devices would be in question, since what > I read did not list them. <snip wild speculation> If you don't know what it is talking about, then it really does not support any point at all, so why bother raising it? -- Flash Gordon |