API Design
in [General Programming]
|
Prev: Water plant design | Design Build | Water plant construction
Next: Two programs with same logic
From: Nobody on 21 Dec 2009 19:51 On Mon, 21 Dec 2009 04:11:01 -0800, gwowen wrote: >> Today's embedded processors are huge machines by yesterday's standards. > > Sure, some of them are. But the fact remains that tiny embedded > processors are still produced in enormous numbers, because they're > cheap. TI sell 16bit chips with 1kb of flash and 128bits of memory for > 50 cents. For 4 or 5 dollars, you can get a full 16kb of RAM. Good > luck running a garbage collector on that. For 16kB, GC isn't out of the question, particularly for restricted cases (e.g. strings; GC is somewhat simpler when you don't have to worry about circular references).
From: Pascal J. Bourguignon on 21 Dec 2009 20:09 Chris McDonald <chris(a)csse.uwa.edu.au> writes: > "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 Garbage collection is as old as LISP, AFAIK. That is 1960 or 1961. Notably, IPL was lacking a garbage collector. -- __Pascal Bourguignon__ http://www.informatimago.com/ WARNING: This product warps space and time in its vicinity.
From: Thad Smith on 21 Dec 2009 21:19 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. Further there are listed and unlisted exceptions. The most fundamental one, for the compiler I use, is lack of function recursion. It could be done (by a different compiler design), but would result, for my target, in a significantly higher overhead for function calls and data access, due to processor architecture. The trade-off makes sense for the intended processor/application combination. I often compile my target code to run on a PC, using gcc or similar compiler, for testing algorithms. I am careful, of course, to keep target-dependent code separated. I suppose you can say that I am programming in a C dialect, with 99% of the code straight C. Fully ISO compliant? No, but very usable. Large payoffs come if I decide to port to another processor. Also note that there exist gcc cross compilers for a few small processors, resulting in a high level of C compliance in those cases. -- Thad
From: BGB / cr88192 on 21 Dec 2009 23:59 "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... >> my reasons for using C are varried, although, part of it may be that most >> of the code I write is library code (mostly for my own uses), and also I >> use some amount of "reflection", which does not work so well with C++ >> (mostly giving the non-standardized name mangling and compiler behaviors, >> ...). > > Probably especially libraries and code for compilers. > granted. >> 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?... >> Java is one of those languages: >> one hears about it enough, but where is the code?... > > We have a fair bit which we sell. > ok. >>>> 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?... >> 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... >>>> 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... >>>> Only if you have real time requirements GC could be a problem. >>> Or limited resources, or no operating system! >> >> the original PDP's were not exactly overflowing with RAM, and this is >> where GC got started... >> >> GC need not necessarily mean big memory... > > Limited resource does not necessarily mean limited RAM. It could be > limited code space, or limited time, or limited power (so wanting the > processor to be idle)... > ok. >> it may depend some though on how one defines and implements said GC >> though, as some strategies make more sense than others. > > Obviously that makes a difference, and strategies will have improved over > the years. > yeah... a very simple form of "GC" is, actually, the use of a rotating buffer... granted, one could debate that this is really a GC, since it doesn't really allocate or preserve anything, one just has to be sure that the work is done (or the data is copied out), before the data gets overwritten... >>>> 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, keyboard controller which operates via USB, USB-connected drives faking being connected via ATA when the BIOS boots them, ...). I suspect "something" is going on here... NIC or USB are far too new, and almost invariably have actual electronics. however, I am not sure which exact devices would be in question, since what I read did not list them. maybe: the PIT + PC-speaker; aspects of the ATA / IDE controller?; ST-506 controller?; the A20 line? the keyboard controller? UART and parallel port?; IRQ controller? .... somehow, I think it is probably emulated (though by the video card), whenever one tries to use old-style VGA or CGA or Hercules or ... video modes, as I am left doubting that modern video cards actually use actual special HW for this. more so, noting how these modes work with an HDMI-connected LCD flatpannel, and the VGA controller was not exactly set up by giving it some particular mode number or resolution (it would instead be given a bunch of bits to effect things like CRT timing and some things which effected how it accessed memory, and would somehow automagically convert this into a particular resolution, ...). in all sense, CRT timings would be meaningless to an HDMI-connected flatpanel, yet oddly enough code which uses VGA registers from real-mode still works, ... > Oh, and a lot of the time you have processors embedded in to ICs, there is > a whole market in processor designs for programming in to the various > forms of programmable logic devices. ok. > -- > Flash Gordon
From: BGB / cr88192 on 22 Dec 2009 00:16
"Nobody" <nobody(a)nowhere.com> wrote in message news:pan.2009.12.22.00.51.36.16000(a)nowhere.com... > On Mon, 21 Dec 2009 04:11:01 -0800, gwowen wrote: > >>> Today's embedded processors are huge machines by yesterday's standards. >> >> Sure, some of them are. But the fact remains that tiny embedded >> processors are still produced in enormous numbers, because they're >> cheap. TI sell 16bit chips with 1kb of flash and 128bits of memory for >> 50 cents. For 4 or 5 dollars, you can get a full 16kb of RAM. Good >> luck running a garbage collector on that. > > For 16kB, GC isn't out of the question, particularly for restricted cases > (e.g. strings; GC is somewhat simpler when you don't have to worry about > circular references). > yep, and GC need not be some piece of esoteric machinery which one gives over all their memory alocation to and hence-forth never use manual handling again. this is merely one form of GC. one could instead define it more loosely, as a methodology where the code responsible for creating objects is not necessarily also responsible for freeing them... a simple example would be that, for example, a piece of code uses items of a given type, and when fetching an item will mark it; more so, the overall process is handled in units, so that if an item it not touched in a given unit, we can know it is no longer needed (there is no external persistent state); so, at the start of the unit, all marks are cleared, and during operation the units are marked; at the end of the unit, any items which were not marked are released (or marked free). this can be considered a form of GC, but with almost no overhead for these sorts of use cases, and leads to simpler and more efficient code than would be the case if the items were tracked directly. likewise for fixed-size rotating spaces or buffers, or even simply clearing or discarding all the contents of a given "heap", ... so, it depends a lot on ones' definitions and specific situation... |