API Design
in [General Programming]
|
Prev: Water plant design | Design Build | Water plant construction
Next: Two programs with same logic
From: Markus Schaub on 22 Dec 2009 09:31 jacob navia schrieb: > gwowen a �crit : >>> 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. > > Sure, you have 16 BYTES of memory and you want C to run in that? It's not 128 bits, it's 128 bytes. Markus
From: Gareth Owen on 22 Dec 2009 10:31 Markus Schaub <usenet(a)markus-schaub.de> writes: > It's not 128 bits, it's 128 bytes. Sorry, my mistake.
From: Richard on 22 Dec 2009 10:39 Marco <prenom_nomus(a)yahoo.com> writes: > On Dec 20, 4:42 pm, jacob navia <ja...(a)nospam.org> wrote: >> Stefan Ram a écrit : >> >> >> >> > Nobody <nob...(a)nowhere.com> writes: >> >> The situation is different for a long-lived process (i.e. interactive >> >> application, daemon, etc), where even a small leak can eventually grow to >> >> dominate memory consumption (although you also have to worry about heap >> >> fragmentation in that situation). >> >> > Or for code in a library, when it is unknown, which kind of >> > process will use it. Since the subject of this thread is >> > »API Design«, this might be relevant here. >> >> > Some of you will already know the following quotations, >> > because I have already posted them into Usenet before. >> >> > »There were two versions of it, one in Lisp and one in >> > C++. The display subsystem of the Lisp version was faster. >> > There were various reasons, but an important one was GC: >> > the C++ code copied a lot of buffers because they got >> > passed around in fairly complex ways, so it could be quite >> > difficult to know when one could be deallocated. To avoid >> > that problem, the C++ programmers just copied. The Lisp >> > was GCed, so the Lisp programmers never had to worry about >> > it; they just passed the buffers around, which reduced >> > both memory use and CPU cycles spent copying.« >> >> The lcc-win compiler system provides a garbage collector in its standard >> distribution. > > I respectfully disagree that this belongs in the C language. The C Do you think C has a place for something like sort algorithms too "Marco"? > language is essentially portable assembly language and should remain Huh? What languages are not? > 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. He has your permission eh? Cos that makes sense create a whole new language! > > Of course, anybody can create C API libraries for others to use with > as many features as you desire. We thank you from the bottom of our hearts. You contributions duly noted. -- "Avoid hyperbole at all costs, its the most destructive argument on the planet" - Mark McIntyre in comp.lang.c
From: Richard on 22 Dec 2009 10:41 "BGB / cr88192" <cr88192(a)hotmail.com> writes: > "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...). How long have you been a programmer? I hope not too long. What the hell kind of inference can you make from the high level scripting language to the underlying compiled language?
From: Flash Gordon on 22 Dec 2009 15:19
BGB / cr88192 wrote: > "Flash Gordon" <smap(a)spam.causeway.com> wrote in message > news:fbh607xbh4.ln2(a)news.flash-gordon.me.uk... >> 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 : <snip> >>>>> 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). > > I have seen the source for many of the apps I use (or have general > background knowledge), since, apart from Windows itself, I mostly use > open-source software... Ah well, if you only use OSS it is different. A lot of people don't have that as an option. > I am frustrated though some by what apps I know of which are written in > large part in Python, since nearly every app I have seen which has > components in Python has been slow and buggy... > > although, I know of another app which had some issues like this, but had > observed in this case that some parts of the app were written in Tcl... I've come across slow and buggy SW written in C. It happens in all languages. I don't know if any language is worse than another for it. > there is something to be said for static typechecking, since at least it > will weed out most of the errors before they show up at runtime (in the form > of ugly death messages, such as a typecheck error, missing object field, > incorrect number of method arguments, ...). Static type checking can help, but if you really want that then C is the wrong language since the type system is pretty weak. >>>>>>> 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... > > I don't use these either (not like they would be available where I live > anyways, given "here" is approx 20 miles from the city limits, and this here > is the desert, and my house is on a dirt road, ...). Then your air-con... OK, so some really old air-cons might not have processors. > (around here, the UPS people don't knock, they sneak up, leave the packages, > and try to get away quickly... it is ammusing some...). one typically knows > a package has arrived when they hear the UPS guy stomp the gas to get > away... Well, the UPS driver will have loads of embedded devices in his van. > granted, my parents drive... And probably in their car. >>>>>>> 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. > > at least, in their original forms, now in all possibility some these devices > are faked in SW in the bus controller, from what I had read some... Oh, I don't doubt that some of the are faked in other embedded devices. >>> 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). > > not the one in the keyboard... > > the one that is controlled via ports, and by setting the right values causes > the computer to reboot... > > older keyboards communicate via the computer via a special serial bus, and a > chip on the motherboard served as a controller. other times, the keyboard > can be connected via USB, but the same IO ports still look and behave the > same (even though, in all sense, USB is wired up to the computer, and sends > its scan codes differently, than would have been sent via a keyboard using a > serial connection and a DIN-5 plug...). I know a little about how the old keyboards worked, since one of the things I came across way back (in the 80s) was instructions for uploading a very small program in to the processor in the keyboard. A long time ago, so I don't have the details now ;-) I can't guarantee if was for a PC, but with a serial interface to the keyboard you probably had a processor at each end of the link! >>> 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. > > but, they may end up looking to the OS and DOS software as if they were > connected ATA (although, observably, Windows and Linux see through this > trick, where Linux sees both USB and SATA drives as SCSI devices,> rather > than as legacy ATA devices, and 64-bit Windows doesn't boot correctly from > USB...). I can't say I've looked too deeply in to USB drives, but I would not be surprised if they were basically running SCSI over the USB interface. SATA drives are another matter. <snip> >>> 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! > > but, they were not typically onboard or standardized until the 2000's... I'm sure they were standardised a lot before then (although there are newer standard now). Not onboard though. > the NIC was usually a separate card, which required special drivers and > such. They *still* require special drivers, it's just that the drivers generally come with the OS now. > this is in constrast to HW which was there since the beginning, and more or > less has to be present so that backwards compatibility is maintained (say, > with old DOS software which directly messes with IO ports, ...). > > it is most notable that many of these IO ports still work on newer systems, > even if presumably the underlying HW and mechanisms have chainged. Actually, I believe the old way of doing it is faked. Just as USB keyboards get faked to appear as PS/2 keyboards. > I expect there IS a probably a processor somewhere in this case, maybe if > doing little more than watching IO ports and redirecting things or > something... The NIC will have a processor, and a decent one will be doing rather more than just watching the IO ports. Even a cheap one does more than watch IO ports! For other stuff it probably varies. There may be a processor encoded in to a PLD, or maybe a processor embedded in an IO device... >>> 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? > > it is speculation based on my own prior OS dev work (from years ago), > although I am a little fuzzy on my memory of which all devices exist or > which IO ports they use (but, I have done enough OS dev, and seen enough how > DOS apps work, that for them to continue working, likely these devices are > still in place, presuming modern computers can still boot DOS and run DOS > SW, which last I had seen, they still do...). Ah well, I'm talking based on having looked ages ago at some HW documentation, and knowing some of the technologies in use in the embedded world. > the part I most remember though is the VGA registers and how the thing got > set up for things like ModeX and 640x480x16 color, ... but, even this is > faded... That will all be faked. > all it really said much was that the bus controller in question: > emulated legacy hardware; > had the code for such legacy HW written in C. > > although, it was a bus controller for an unorthodix x86 chipset (I think > Intel Atom or VIA Nano or similar), and it is possible that for more > traditional computers, the HW is not so much emulated?... A lot of the time chipsets like that actually do it by having multiple devices on the one piece of silicon which previously would have been on several pieces of silicon, but not necessarily always. > then again, even x86 is emulated, even on its own mainstay chips... Microcoded processors have been around for rather a long time. -- Flash Gordon |