API Design
in [General Programming]
|
Prev: Water plant design | Design Build | Water plant construction
Next: Two programs with same logic
From: jacob navia on 22 Dec 2009 13:08 Markus Schaub a �crit : > jacob navia schrieb: >> 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 128 BYTES!!!!! WOW! That changes everything. Of course you will need a GC for that amount of RAM. :-)
From: BGB / cr88192 on 22 Dec 2009 13:15 "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 : >>>>> 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. > yep. > <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. > yep, that is a reason in my case as well... similarly, most of the coding I do is also open-source... > <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. > ok. >>>> 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... 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... 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, ...). >>>>>> 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, ...). (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... granted, my parents drive... > >>>>>> 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... >> 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...). >> 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 suspect "something" is going on here... > > There is a lot going on here. > yeah. >> 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... the NIC was usually a separate card, which required special drivers and such. 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. 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... >> 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...). 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... 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?... then again, even x86 is emulated, even on its own mainstay chips... > -- > Flash Gordon
From: BGB / cr88192 on 22 Dec 2009 13:30 "Richard" <rgrdev_(a)gmail.com> wrote in message news:hgqpaq$uoj$2(a)news.eternal-september.org... > "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. > I have actually been doing C coding for around 15 years now, or, IOW, a decent portion of my life thus far (given I was born back in the 80s...). > What the hell kind of inference can you make from the high level > scripting language to the underlying compiled language? usually, there are correllations, especially as can be noted if one has much familiarity with the Quake-family engines. often, in these engines, the script language is a fairly direct manifestation of the underlying engine architecture. Quake1 was scripted in QC, which was C-like, but used an unusual object system (though, still fairly solidly rooted in its underlying implementation). IOW, these script languages tend to be mostly wrappers for the underlying engine machinery, and also for providing for all of the game-related behaviors (such as items, ...). Quake2 and Quake3 used C, although in Quake3 it was compiled to bytecode and JIT'ed at runtime (or interpreted on non-x86 archs). Quake 1, 2, and 3 also were written in C, and I have a decently good understanding of the engine source in both cases (although I am most familiar with Quake 1...). this is because id tended to release their engine source some time after their next major games went to market. Doom 3 seems to use a scripting language which uses class-instance OO, which is unusual for them... if the script is doing this, it may be a possible indicator for their underlying engine architecture (the possibility that this, too, uses class/instance?...), although this is a weak assertion, and id has not released the Doom3 engine source as of yet. similarly, it can be noted that Valve had started their work based on the Quake1 engine, but had fairly quickly migrated to C++ for Half-Life, ... or, it could just be that id is doing like in my case, where I use class-instance some in scripting, even though most of my codebase remains in plain C.
From: BGB / cr88192 on 22 Dec 2009 13:34 "jacob navia" <jacob(a)nospam.org> wrote in message news:hgr1uc$u8f$1(a)aioe.org... > Markus Schaub a �crit : >> jacob navia schrieb: >>> 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 > > 128 BYTES!!!!! > > WOW! > > That changes everything. > > Of course you will need a GC for that amount of RAM. > > :-) with 16x more you could have the NES... although, I guess they had 64kB for ROM, and used banking or similar from what I remember...
From: robertwessel2 on 22 Dec 2009 16:40
On Dec 22, 2:19 pm, Flash Gordon <s...(a)spam.causeway.com> wrote: > BGB / cr88192 wrote: > > 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! I can verify that. There was an 8042 (a microcontroller) on the motherboard of the original PC (and XT). It had a serial port that accepted input from the keyboard. Those keyboards had another microcontroller (8031 or 8042 depending on version) than handled scanning, debounce, repeat, etc., and would send the resulting scan codes over the serial link. On the AT the serial link became bidirectional and you could send commands to the keyboards, to set the repeat rate, set the indicator lights (there were none on the PC/XT keyboard), and some other stuff. The PS/2 style keyboard basically extended the AT approach a bit. While the newer keyboards still have a processor inside, it hasn't been a discrete 8031 or 8042 in many, many years, and these days keyboards (and mice) have full (peripheral) USB stacks in them. > 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. Yep. Other than SATA hard drives, pretty much everything uses SCSI commands - including non-hard drive PATA devices (often called ATAPI devices or packet ATA - for example, most CD-ROM drives). Most storage type devices on USB, Fibre Channel, Firewire, PATA and SATA (excluding parallel and serial ATA hard drives) use SCSI commands (not to mention many non-storage-type devices). > > 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. It's the BIOS which fakes the old style (PS/2) keyboard and mouse port using SMI mode on the processor. Many OS's that understand USB take over the keyboard and drive it in USB mode directly (Windows XP, and later, for example). |