Re: API Design
Thad Smith
> http://cacm.acm.org/magazines/2009/5/24646-api-design-matters/fulltext
>
>
> Communications of the ACM rarely bring something practical.
> This is a good exception.
>
> It is a good article about API design, and the problems of bad APIs.
Agreed. I plan to distribute the link to others at work. It makes
explicit the policy-free vs. policy-rich trade-off, which is a useful
insight for me.
Good design of low-level functions has a multiplying effect on
application code.
Followups set to comp.programming.
--
Thad
William Ahern
> jacob navia wrote:
> > http://cacm.acm.org/magazines/2009/5/24646-api-design-matters/fulltext
> >
> >
> > Communications of the ACM rarely bring something practical.
> > This is a good exception.
> >
> > It is a good article about API design, and the problems of bad APIs.
> Agreed. I plan to distribute the link to others at work. It makes
A good API emerges from iteration. You really can't know how to make a new
API work for you until you've used it in various situations. Tweak, use,
tweak use. Sometimes after two or three iterations you have a really solid
design, sometimes you need more. A couple of the authors suggestions in that
paper reflect this dilemmea, with the vain suggestions about documentation
and separating the caller from implementor.
Iteration is extremely hard to accomplish in a commercial environment with
other engineers because re-writing code is usually frowned upon, especially
once others have begun using the interface. (Thus if you separate caller
from implementor you'll never get the opportunity to change the API; and
it's foolish to think the first try will be even remotely optimal.)
This is why C++, Java, and C# are so popular commercially. For one thing, if
you implement a canonical design pattern, no matter how unwieldy or
overkill, nobody will object. Second, these interfaces can just be papered
over with super/sub classing on an ad hoc basis. This is also why the claims
of improved modularity in these OOP languages are baseless, because in
practice cross-dependencies grow very quickly.
One strategy is to write mock-up software in, say, Perl. The standard forms
in Perl reduce to C code rather well, as long as you're not using too many
modules. And of course design iteration in Perl is much faster than in C.
The interesting thing about C and design patterns is that though you can
obviously implement a design pattern in C, it's very difficult to implement
it in a universal fashion. It will almost always be closely bound to the
particular context. And this, I propose, is good thing!
James Harris
> http://cacm.acm.org/magazines/2009/5/24646-api-design-matters/fulltext
>
> Communications of the ACM rarely bring something practical.
> This is a good exception.
>
> It is a good article about API design, and the problems of bad APIs.
It is a good article though I'd take exception to his criticisms of
the C select function. If it were to do as he suggests and return a
number of fds without overwriting the input fd set it would have to
return newly allocated memory which it would be left to the caller to
free. This could be done but it would be unusual for C functions
wouldn't it? IIRC some of the string functions return new objects but
most other C functions seem to go to lengths to avoid doing so.
- in anticipation that someone will correct me if my impression is
wrong....
James
Ian Collins
The Unix select function is pretty clunky, but at least it does provide
a clearly documented means for passing an indefinite timeout.
Note that Unix also provides the poll function, which provides a cleaner
interface that preserves the original socket lists. If I were inventing
a new framework, I'd use poll rather than select.
See http://opengroup.org/onlinepubs/007908799/xsh/poll.html
--
Ian Collins
Pascal J. Bourguignon
You could pass it two vectors, one with the fds to select, and one
with space for the results (times three of course).
Or you could use a garbage collector, but then select couldn't be a
syscall anymore.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Specifications are for the weak and timid!"
Jens Thoms Toerring
> On 17 Dec, 17:06, jacob navia <ja...@nospam.org> wrote:
> > http://cacm.acm.org/magazines/2009/5/24646-api-design-matters/fulltext
> >
> > Communications of the ACM rarely bring something practical.
> > This is a good exception.
> >
> > It is a good article about API design, and the problems of bad APIs.
> It is a good article though I'd take exception to his criticisms of
> the C select function.
select() isn't a genuine C function (in the sense that it's part
of the C standard) but comes AFAIK from UNIX/POSIX;-)
> If it were to do as he suggests and return a
> number of fds without overwriting the input fd set it would have to
> return newly allocated memory which it would be left to the caller to
> free.
As far as I can see the function could also take a pointer to three
further fd_set's that belong to the caller and just modify those,
couldn't it?
On the other hand, there may have been also other considerations
when the select() function was invent a long time ago like speed,
memory requirements etc. on machines at the time, so I would be a
bit careful about blaming the original authors about coming up
with a bad API when I don't know all the factors they had to take
into account.
> This could be done but it would be unusual for C functions
> wouldn't it? IIRC some of the string functions return new objects but
> most other C functions seem to go to lengths to avoid doing so.
I can't remember a single standard C string function that does
that, they all seem to operate on user supplied memory. Perhaps
you're thinking about some non-standard-C (but POSIX) functions
like strdup()?
> - in anticipation that someone will correct me if my impression is
> wrong....
- me too;-)
Regards, Jens
--
\ Jens Thoms Toerring ___ j...@toerring.de
\__________________________ http://toerring.de
Chris McDonald
>I can't remember a single standard C string function that does
>that, they all seem to operate on user supplied memory. Perhaps
>you're thinking about some non-standard-C (but POSIX) functions
>like strdup()?
Not really wishing to steal the thread, but I've often wondered why
strdup() has not appeared in the C standard. Could a reason be because
it *does* return allocated memory?
--
Chris.
Hallvard B Furuseth
> In comp.lang.c James Harris <james.h...@googlemail.com> wrote:
>> This could be done but it would be unusual for C functions
>> wouldn't it? IIRC some of the string functions return new objects but
>> most other C functions seem to go to lengths to avoid doing so.
>
> I can't remember a single standard C string function that does
> that, they all seem to operate on user supplied memory.
Right. Or on static/program-allocated memory - asctime(), getenv(),
strerror().
There is fopen() which might allocate memory, but it has its own
function (fclose) which will free it.
> Perhaps you're thinking about some non-standard-C (but POSIX)
> functions like strdup()?
--
Hallvard
Malcolm McLean
"Chris McDonald" <ch...@csse.uwa.edu.au> wrote in message news:
memory allocation library. Just for one trivial little function, it wasn't
considered worth it.
Flash Gordon
I very much doubt that is the issue, since both the sting functions and
memory allocation functions are in the *same* library, the standard C
library. As I understand it this was more a matter of philosophy, that
is was decided that the str* and mem* functions do not allocate memory,
and the only functions to allocate memory which needed a call to free
would be the *alloc functions.
Maybe a proposal for stralloc would have been seen more favourably ;-)
--
Flash Gordon
BGB / cr88192
"Malcolm McLean" <regn...@btinternet.com> wrote in message
news:COOdnUq8IKa8Y7DW...@bt.com...
and, oddly, I have a lot of special purpose 'strdup' functions which tend
instead to intern the strings...
I think it is mostly that 'strdup', as is such, is too convinient for what
it does.
it makes it really easy to just grab strings and forget, creating memory
leaks with every call.
I tend instead to intern the strings (for various API's, which happen to
include strdup-like functions), so that I can just as well use it as a
trivial "make sure string will not disappear" function.
all is not ideal though, since many of these APIs don't otherwise check or
GC these strings, and hence the memory is not reclaimed (and, hence, these
functions end up "not to be used" for one-off strings or buffers, ...).
granted, absent buffers, typically the memory creep is likely to be small
enough to be ignorable (a string table somewhere which gradually gets larger
with old dead strings never to be seen again).
usage cases for things like this is usually in my dynamic linker or compiler
code, usually for dealing with symbol names (variable names, function names,
...), ...
other, more frontend API calls, similarly "merge" strings, but instead use
the GC and a weak hash to dispose of them.
I guess this is mostly part of my own "unique" mindset, as I tend to see
most strings as atomic units on which operations are performed. thinking of
strings as character buffers is a little odd to me, as I tend to treat them
somewhat differently (a character buffer is for doing work, but a 'string'
is an immutable atomic unit).
or such...
>
>
Malcolm McLean
> "BGB / cr88192" <cr8...@hotmail.com> writes:
>>it makes it really easy to just grab strings and forget,
>>creating memory leaks with every call.
>
> might be appropriate. For a program with a large or
> indeterminate run time, it might show that either the wrong
> programmer was chosen or the wrong programming language.
>
To me, any memory leak is a big red flag. Not so much for technical reasons,
but because it suggests that the programmer has lost control of his logic.
Nobody
>> For a program with a small run time and memory usage, this
>> might be appropriate. For a program with a large or
>> indeterminate run time, it might show that either the wrong
>> programmer was chosen or the wrong programming language.
>>
> To me, any memory leak is a big red flag. Not so much for technical reasons,
> but because it suggests that the programmer has lost control of his logic.
For typical Unix "commands", it's often not worth tracking memory
allocations. Everything will be freed when the process terminates.
Managing memory is easy when the pointer returned from a function is
*always* allocated by that particular call. But if you consider the case
where the object may already exist as a "shared" value (e.g. interned
strings), you can either:
1. Duplicate the object and require the caller to free() it. This is
wasteful if callers often retain the value for the duration of the process.
2. Return an indication of whether the caller should free it. This
information then has to be passed around with the pointer, complicating
the code.
3. Implement some form of garbage collection.
4. Don't worry about it. Sometimes this will result in more memory being
used than is strictly necessary.
Sometimes, #4 is the rational choice. Particularly, if the allocations are
likely to constitute a fixed (and relatively small) overhead per process,
or can otherwise never amount to more than a small proportion of the
process' total memory consumption.
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).
Robert Maas, http://tinyurl.com/uh3t
> > It is a good article about API design, and the problems of bad APIs.
> Agreed. I plan to distribute the link to others at work. It makes
> explicit the policy-free vs. policy-rich trade-off, which is a useful
> insight for me.
Agreed, good article, thanks for "carrying" it to comp.programming
where I could discover it. I have just one quibble: It seems to
claim that the solution to API design, and software in general, is
open source. It's my understanding that open source is vounteer,
pro bono, no pay for work. The article seems to imply that all
software programming should be pro bono, nobody ever to get paid
for writing software. So all software programmers who still have
paying jobs should quit their commercial jobs and live off public
assistance, i.e. live in poverty while they spend 60 hours per week
doing open-source programming for free.
I've been told I could *still* earn a living, not by writing the
open-source software itself, but by consulting, explaining how to
use the open source software. But it seems to me that only
encourages writing software that is difficult to use and not
properly documented (except in secret documents I keep to myself),
because if software is very easy to use and well documented then
nobody would need to hire me to show them how to use it.
Thus open source as the primary way that software is written either
terminates any chance of earning a decent living by software
programming, or results in bad software that needs a consultant to
show how to use it either of which is bad IMO.
I'm thinking that semi-open-source software would be a better idea.
The software itself is kept secret, posted only on my own Web site
and accessiblbe only via the API, while the API is open. Thus the
API can be publicly critiqued to make sure it is easy to use and
well documented, and then the code itself can be tested by anyone
who wants to test it (and who is willing to pay for the usage fee
for however much they use the software), and anyone who finds a bug
can embarrass the programmer by openly posting how to excite the
bug, thereby achieving quality control in the code. Maybe (for
spotting bugs) being able to test the code without seeing the code
isn't quite as good as being able to see the code, but for that
trade-off the programmer can get paid for use of the code, hence
get paid for writing it in the first place (if people then actually
use it).
The question then is what payment model to use for
network-accessible software. Traditional methods are to pay per
metered usage ("cloud computing" seems to be using this model), or
to pay a license for unmetered usage or for pre-paid usage up to
some limit (Unix shell ISPs, PPP connection service, and some
Web/DB hosting services, use this model), or to use various forms
of advertising to support usage (Yahoo and Google uses this model,
as do most "free" hosting services). All of these involve money
changing hands, either from users or from advertisers. I am
currently developing an alterate type of payment, replacing
standard currency (US$ or whatever) by labor-time currency. The
user performs some kind of useful labor on behalf of the software
system, to earn labor credits, which are then used to pay for
metered service. Labor credits can also be used to pay for
third-party service: Pseudo-employer posts Request For Bids (RFB),
pseudo-employee makes bid in the form of *time* it will take to
complete the contract, lowest bidder gets contract, must complete
all work within the time that was bid, and if the work is
satisfactory then the pseudo-employee receives labor-credit for
exactly the amount of time that was bid. Thus work performed for
the system generates "seed" funds which are then used as currency
for third-party employment. Thus if I personally can find some
software service I provide which lots of people want to use, I can
rent my service to lots of users in return for those users either
directly providing me with services I want or providing services to
other users who provide services to me.
Now a new idea I came up just now: If and when the labor-credit
currency on my system becomes well respected as valuable, my system
could manage third-party software rentals. One user earns labor
credits on my system, uses them to purchase software usage from
another of my users, and then that second user uses the earnings in
the usual way purchasing services from me or other users. Thus only
I would need to set up the basic economic system to keep track of
labor credits and handle bidding on contracts and handle
third-party transfer of credits per third-party services provided,
while *every* software programmer could set up net-accessible
services and link them into my system to get paid for usage of
their software. To prevent any significant amount of cheating, i.e.
charging a lot of money for services that are worthless, I'd
restrict my third-party software rentals to small units of work,
pre-paid, less than a doller of equivalent monetary value per
transaction unit, and I'd vet each new software service *myself*
before offering it for others to rent through my system. My
pre-vetting means the software is already known as probably useful
before any of my users risk funds to rent it, and if after the
software has worked for me it ceases to work for some other user
they lose at most less than a dollar of labor credits, and I can
afford to offer a refund if I confirm they got ripped off, and of
course then I expect the no-longer-good software service to either
give me back what I refunded or convince me the service was good
after all, or terminate use of my system.
Caveat: I still am looking for the "killer application" that I can
provide directly on my system, to induce hundreds of people to
desire to use that application, thereby inducing each of them to
get an account on my system and then perform work for my system to
pay for getting the services that my application will provide.
TinyURL.Com/MayProj contains a list of lots of possible
applications I might like to provide, but so-far nobody else has
shown much interest in *any* of them. TinyURL.Com/NewEco is a
rather verbose sorta-blog of the concept behind my upcoming
labor-exchange economic system. TinyURL.Com/Portl1 links to the
current portal into a prototype NewEco system, which at present
includes maintenance of user accounts, "Turing" questions to obtain
some preliminary credit and prove you aren't a spambot, and one
actual feature: Surveys/polls. New accounts have 5 seconds of
credit, but you need at least 6 seconds of credit before you can
get into surveys/polls, so you need to answer at least one "Turing"
question to get a few more seconds of credit before you can get
into surveys/polls. The main reason surveys/polls are implemented
already is to get users to vote for which feature they'd most like
implemented, which is most likely to be my "killer application" to
attract more users/customers to my NewEco.
jacob navia
>
> 3. Implement some form of garbage collection.
>
The lcc-win compiler system provides a grabage collector in its standard distribution.
I have been arguing this solution for years but not many people here listen. It is the best
solution: keep the money for the cake AND eat it!
jacob navia
> Nobody <nob...@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).
>
> 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.
> <XNOkd.7720$zx1....@newssvr13.news.prodigy.com>
>
> �A lot of us thought in the 1990s that the big battle would
> be between procedural and object oriented programming, and
> we thought that object oriented programming would provide
> a big boost in programmer productivity. I thought that,
> too. Some people still think that. It turns out we were
> wrong. Object oriented programming is handy dandy, but
> it's not really the productivity booster that was
> promised. The real significant productivity advance we've
> had in programming has been from languages which manage
> memory for you automatically.�
>
Exactly.
> http://www.joelonsoftware.com/articles/APIWar.html
>
> �[A]llocation in modern JVMs is far faster than the best
> performing malloc implementations. The common code path
> for new Object() in HotSpot 1.4.2 and later is
> approximately 10 machine instructions (data provided by
> Sun; see Resources), whereas the best performing malloc
> implementations in C require on average between 60 and 100
> instructions per call (Detlefs, et. al.; see Resources).
> And allocation performance is not a trivial component of
> overall performance -- benchmarks show that many
> real-world C and C++ programs, such as Perl and
> Ghostscript, spend 20 to 30 percent of their total
> execution time in malloc and free -- far more than the
> allocation and garbage collection overhead of a healthy
> Java application (Zorn; see Resources).�
>
> http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html?ca=dgr-jw22JavaUrbanLegends
>
> (OK, then garbage collection will take time in addition to
> the allocation calls, but when a program only runs for a
> short time, garbage collection might never be needed.)
>
Exactly
Robert Maas, http://tinyurl.com/uh3t
> What I wrote for myself and what also comes in handy
> sometimes, is an sprintf-like function that allocates
> a sufficient buffer and then prints to that buffer.
> This is a generalization of strdup.
That sounds like you need to traverse the list of parameters twice,
once to just determine how many characters each datum would require
to print, which for %s and %d parameters depends on the actual
data, and then the second time to actually format the data into the
buffer that's exactly the right size. And if any of the data
*changes* between the time you measure its print-length and the
time try to actually format it, for example if you're trying to
display a message showing packet totals on a live socket, the
discrepancy crashes your application. I don't like that idea at
all!
IMO it would be better to directly format the data *the*first*time*
into chunks of fixed length, linked-listed, and then just before
return you add up the lengths of the used portion of all the chunks
to allocate one just-right-size buffer, copy the chunks into it,
and reclaim the storage for the chunks and the linked list.
Common Lisp has a "string output stream" which is an output stream
that feeds into a string rather than into an I/O channel, which
most likely works like that, writing data into I/O buffers, but
just linking them into a list instead of flushing them FIFO to an
I/O device, then building a string of the correct length before
return.
Robert Maas, http://tinyurl.com/uh3t
> >creating memory leaks with every call.
> For a program with a small run time and memory usage, this
> might be appropriate. For a program with a large or
> indeterminate run time, it might show that either the wrong
> programmer was chosen or the wrong programming language.
And even for medium-length interactive applications if memory usage
is small enough. For example, I've been running CMU Common Lisp
with GC disabled for the past several months, because that's the
only practical way to avoid a bug wherey the second GC in any run
will crash fatally due to confusion over page-fault signals in
FreeBSD Unix. The current coreimage was started about a week ago,
and so-far it's used less than 128k out of 512k available, so I can
probably run it another three weeks, then do a single GC, then run
it another month. My CGI applications have been running with GC
disabled too, and work better than they ever did with GC active!
With 64k bytes of RAM, you need GC. With 512MB of RAM, maybe not.
Ian Collins
But it isn't practical on the majority of platforms C is used on these days.
--
Ian Collins
jacob navia
Look, C++ is the best language in the world and C is a old shit.
We know that. You have told us countless times. C is for embedded systems
too small to support C++ and will disappear soon. OK We KNOW that by now, it is
not necessary to repeat it at each message.
BGB / cr88192
>>creating memory leaks with every call.
>
> might be appropriate. For a program with a large or
> indeterminate run time, it might show that either the wrong
> programmer was chosen or the wrong programming language.
>
well, the big issue is mostly one of convinience:
it is a lot more convinient to simply forget about strings than to worry
about freeing them;
similarly, since strings tend to be fairly small, very often the code can
leak pretty badly and still keep running just fine (since the app will
almost invariably be exited and restarted before the leak becomes too much
of a problem).
but, this is the issue:
the convinience may prompt bad style...
hence, interning strings is at least a little better, because it allows a
similar convinience while generally bounding memory use (only as much memory
will be use as there are unique strings in the working set, which in
practice is typically much smaller than the available memory).
consider, for example, if a string were interned for every word in a mass of
english text documents. once a finite limit is reached (say, maybe 2500 or
3000 unique words), then this inflation will drop to to almost nothing
(usually periodic random strings, ...).
whereas naive use of strdup will be unbounded (dependent on the total amount
of text processed, rather than the upper bound on the number of unique words
present).
this subtle difference makes a notable difference for "medium length"
running times, especially for higher-activity apps (where a plain memory
leak could kill the app in a matter of minutes, but a more gradual leak may
allow it to last for hours or days or more before crashing...).
granted, it is all far from perfect, but I guess a lot depends on how much
one needs to expect from the code...
for example, what is fine for a command-line tool may not be good enough for
an interactive app, and what is good enough for an interactive app may still
not be good enough if reliability matters. but, then, OTOH, not all apps
need reliability, and for many things it is good enough if the thing only
runs at most a few hours or days at a time...
or, for a command line tool, it may only matter so long as it can process
whatever data it is given.
or (satire), one can make use of newer 64-bit systems as a means for being
even more lazy about dealing with memory leaks...
BGB / cr88192
> Nobody <nob...@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).
>
> process will use it. Since the subject of this thread is
> �API Design�, this might be relevant here.
>
granted.
> 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.�
>
<snip>
>
> (OK, then garbage collection will take time in addition to
> the allocation calls, but when a program only runs for a
> short time, garbage collection might never be needed.)
>
generally agreed.
hence, for many pieces of code, I personally use garbage collection...
the edge case is, however, in C, since the GC is not a "standard" component,
and one may wish to maintain modularity in many cases, not all code may be
able to make use of the GC.
the fallback then is to make use of alternative strategies, such as
allocating data in a region of memory which is periodically either destroyed
or reset, ...
so, it is all so many tradeoffs I guess...
Ian Collins
> Ian Collins a écrit :
>> jacob navia wrote:
>>> Nobody a écrit :
>>>>
>>>> 3. Implement some form of garbage collection.
>>>>
>>>
>>> The lcc-win compiler system provides a grabage collector in its
>>> standard distribution.
>>>
>>> I have been arguing this solution for years but not many people here
>>> listen. It is the best
>>> solution: keep the money for the cake AND eat it!
>>
>> But it isn't practical on the majority of platforms C is used on these
>
>
> We know that. You have told us countless times.
Quote one. I have never claimed that.
I manage a team of 50+ developers, all developing in C.
> C is for embedded systems
> too small to support C++ and will disappear soon. OK We KNOW that by
> now, it is
> not necessary to repeat it at each message.
Please quote an example.
FACT: The majority of new C development is for embedded applications, be
they big or small. I'd wager the majority are on smaller systems where
GC would be impractical.
--
Ian Collins
BGB / cr88192
> Chris McDonald <ch...@csse.uwa.edu.au> writes:
>>Not really wishing to steal the thread, but I've often wondered why
>>strdup() has not appeared in the C standard. Could a reason be because
>>it *does* return allocated memory?
>
> memory, viz., calloc, malloc, and realloc. But it does
> not /mix/ them with functions that do something else.
> It tries to supply low level building blocks and leave
> the mixing to higher levels.
>
> A function that works on a client buffer can work with
> all kinds of storage (allocated, automatic, and static).
> So it's more �policy-free�.
>
> strdup merely combines malloc and strcpy, so when needed
> it can be easily written. It also adds a little bit of
> a policy.
>
> What I wrote for myself and what also comes in handy
> sometimes, is an sprintf-like function that allocates
> a sufficient buffer and then prints to that buffer.
> This is a generalization of strdup.
>
yep...
I can note that both my codebase, and apparently Quake2, ... have functions
along these lines.
granted, my function (of this sort) typically allocate the memory in a
"rotating allocator" (IOW, a region where the allocator just wraps around
and eventually overwrites whatever was there previously), but what exactly
one needs best depends on their use case...
rotators can also be used as a very specialized GC strategy in some cases
(for example, stale objects are eventually freed unless either freshened or
moved out of the rotator).
...
jacob navia
>
> 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.
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). Today's embedded processors are huge machines
by yesterday's standards. Only if you have real time requirements
GC could be a problem. Analog Devices processors and DSP for example
are all 32 bits now.
Only in 16 bits processors with a few kbytes of RAM you could be right.
And so what?
You *can* use a GC in many OTHER applications.
Richard Heathfield
<snip>
> But ["grabage [sic] collection"] isn't practical on
> the majority of platforms C is used on these days.
That's irrelevant to Jacob Navia. He's scratching an itch, which is a
perfectly respectable thing for a programmer to do. And if he wrongly
assumes that everyone else has the same itch, he's hardly unique in
that, is he?
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
Ian Collins
> 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.
> 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.
> 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.
> Only if you have real time requirements GC could be a problem.
Or limited resources, or no operating system!
> 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.
> And so what?
>
> You *can* use a GC in many OTHER applications.
Did I say you couldn't?
--
Ian Collins
Flash Gordon
> Ian Collins a écrit :
>>
>> 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.
Where did he say they don't count?
I think that every new piece of hardware for a PC requiring a driver has
at least one embedded processor, and probably a lot more code than the
sum of the drivers for all the OSs for that HW. Then there is the
software in all the embedded processors in TVs, Radios, cars, airplanes,
MP3 players, DVD players, amplifiers, cookers...
> Your "Facts" aren't facts but assumptions of Mr Collins.
Not facts without proof, but quite likely.
> 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).
In many applications you have hard real time requirements, so you can't
afford things which might take an unknown amount of time, which includes
malloc and free as well as GC.
> Today's embedded processors are huge machines
> by yesterday's standards.
How big is the embedded processor in your phone? How about the one in
your watch?
> Only if you have real time requirements
> GC could be a problem.
Not only then. I've often had to need to know the upper bound of memory
which will be used, and using GC makes that harder and potentially
increases the figure (the memory may not be freed for some time after
the last pointer is destroyed).
> Analog Devices processors and DSP for example
> are all 32 bits now.
There is plenty of stuff other than DSPs. In fact, signal processing is
something where you can need a lot of processing power but not
necessarily much memory. Also a lot of signal processing you know
exactly how much memory you need and don't need *any* dynamic allocation.
> Only in 16 bits processors with a few kbytes of RAM you could be right.
>
> And so what?
>
> You *can* use a GC in many OTHER applications.
Yes, and a lot of people do. However adding it to the C standard without
buggering things up for the applications which cannot afford it is not easy.
--
Flash Gordon
gwowen
> 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).
No. No it isn't. Unless you've got a relatively powerful embedded
processor, like an ARM9, its frequently best not to use the heap at
all.
> 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.
jacob navia
>
>> 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?
Sorry but that is completely out of the question.
gwowen
> Sure, you have 16 BYTES of memory and you want C to run in that?
> Sorry but that is completely out of the question.
Of course it isn't. You can run C program code from the 1kb of
flash. The volatile RAM is only needed for data.
Marco
> Stefan Ram a écrit :
>
>
>
> > Nobody <nob...@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
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.
Of course, anybody can create C API libraries for others to use with
as many features as you desire.
jacob navia
>
> 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.
>
After saying this, you go on saying:
> Of course, anybody can create C API libraries for others to use with
> as many features as you desire.
Well, the GC is exactly that. Absolutely NO changes in the language are needed
at all! Instead of callinc malloc(56) you call gc_malloc(56).
And the good side is that instead of calling free() you do not call anything.
This is in NO WAY a language change!
How do you arrive at that idea?
It is just an API.
BGB / cr88192
"Ian Collins" <ian-...@hotmail.com> wrote in message
news:7p8sac...@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...
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, ...).
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...).
Java is one of those languages:
one hears about it enough, but where is the code?...
>> 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...
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...
>> 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.
>> 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...
it may depend some though on how one defines and implements said GC though,
as some strategies make more sense than others.
>> 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).
Flash Gordon
> "Ian Collins" <ian-...@hotmail.com> wrote in message
> news:7p8sac...@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...
> 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.
> 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.
> Java is one of those languages:
> one hears about it enough, but where is the code?...
We have a fair bit which we sell.
>>> 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.
> 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).
>>> 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!
>>> 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)...
> 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.
>>> 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).
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.
--
Flash Gordon
Chris McDonald
>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.
Malcolm McLean
"Marco" <prenom...@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.
>
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.
Malcolm McLean
>
> Sure, you have 16 BYTES of memory and you want C to run in that?
>
> Sorry but that is completely out of the question.
>
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.
robert...@yahoo.com
> "Ian Collins" <ian-n...@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.
bartc
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
Nobody
>> 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).
Pascal J. Bourguignon
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.
Pascal J. Bourguignon
>> > http://cacm.acm.org/magazines/2009/5/24646-api-design-matters/fulltext
>> > It is a good article about API design, and the problems of bad APIs.
>> From: Thad Smith <ThadSm...@acm.org>
>> Agreed. I plan to distribute the link to others at work. It makes
>> explicit the policy-free vs. policy-rich trade-off, which is a useful
>> insight for me.
>
> Agreed, good article, thanks for "carrying" it to comp.programming
> where I could discover it. I have just one quibble: It seems to
> claim that the solution to API design, and software in general, is
> open source. It's my understanding that open source is vounteer,
> pro bono, no pay for work.
Your understanding is wrong.
Open source is that the customer gets to see the source.
Not that he gets it for free.
> [... a few kilobytes of rant running off a false assumption ...]
What a waste!
Thad Smith
> 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
BGB / cr88192
"Flash Gordon" <sm...@spam.causeway.com> wrote in message
news:4a1507x...@news.flash-gordon.me.uk...
> BGB / cr88192 wrote:
>> "Ian Collins" <ian-...@hotmail.com> wrote in message
>> news:7p8sac...@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
BGB / cr88192
"Nobody" <nob...@nowhere.com> wrote in message
news:pan.2009.12.22...@nowhere.com...
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...
robert...@yahoo.com
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
robert...@yahoo.com
> 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.
Squeamizh
> 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.
BGB / cr88192
<robert...@yahoo.com> wrote in message
news:f1239ae0-8ca9-49e0...@m16g2000yqc.googlegroups.com...
On Dec 21, 10:59 pm, "BGB / cr88192" <cr88...@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, ...
Flash Gordon
> "Flash Gordon" <sm...@spam.causeway.com> wrote in message
> news:4a1507x...@news.flash-gordon.me.uk...
>> BGB / cr88192 wrote:
>>> "Ian Collins" <ian-...@hotmail.com> wrote in message
>>> news:7p8sac...@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
Markus Schaub
> 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
Gareth Owen
> It's not 128 bits, it's 128 bytes.
Sorry, my mistake.
Richard
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
Richard
> "Ian Collins" <ian-...@hotmail.com> wrote in message
> news:7p8sac...@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?
jacob navia
> 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.
:-)
BGB / cr88192
> BGB / cr88192 wrote:
>> "Flash Gordon" <sm...@spam.causeway.com> wrote in message
>> news:4a1507x...@news.flash-gordon.me.uk...
>>> BGB / cr88192 wrote:
>>>> "Ian Collins" <ian-...@hotmail.com> wrote in message
>>>> news:7p8sac...@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
BGB / cr88192
"Richard" <rgr...@gmail.com> wrote in message
news:hgqpaq$uoj$2...@news.eternal-september.org...
> "BGB / cr88192" <cr8...@hotmail.com> writes:
>
>> "Ian Collins" <ian-...@hotmail.com> wrote in message
>> news:7p8sac...@mid.individual.net...
>>> jacob navia wrote:
>>>>>
>>>
>>> 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.
BGB / cr88192
> Markus Schaub a �crit :
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...
Flash Gordon
> "Flash Gordon" <sm...@spam.causeway.com> wrote in message
> news:fbh607x...@news.flash-gordon.me.uk...
>> BGB / cr88192 wrote:
>>> "Flash Gordon" <sm...@spam.causeway.com> wrote in message
>>> news:4a1507x...@news.flash-gordon.me.uk...
>>>> BGB / cr88192 wrote:
>>>>> "Ian Collins" <ian-...@hotmail.com> wrote in message
>>>>> news:7p8sac...@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
robert...@yahoo.com
> 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).
Nobody
> 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...).
id Tech 4 (the engine used for Doom 3 and Quake 4) uses C++.
OOP is a natural fit for games (and other types of simulation).
> Java is one of those languages:
> one hears about it enough, but where is the code?...
Java's strongest constituency is bespoke enterprise software, which
typically never leaves the organisation for which it was developed.
You may as well ask where all the COBOL or RPG-III code is.
Thad Smith
It was a description of the typical C environment for some low-end
processors with poor indexed addressing, not advice (except for the
"grain of salt"). This pertains to the 8051 family and Microchip 8-bit
PIC family, although I think that Microchip has a compiler that supports
recursion for PIC18x and I believe Keil offers recursion as an option
for the 8051 family (you pay the price in less efficient access of the
parameters and auto variables). There are probably several other
low-end architectures for which the limitations also apply.
In general, you tend to think in smaller chunks for smaller processors.
--
Thad
BGB / cr88192
> On Mon, 21 Dec 2009 11:05:54 -0700, BGB / cr88192 wrote:
>
>> 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...).
>
> id Tech 4 (the engine used for Doom 3 and Quake 4) uses C++.
>
> OOP is a natural fit for games (and other types of simulation).
>
yes, ok.
I would have figured as much from what I had seen of Doom 3, although
granted I have not seen any of their engine source.
recently, I have been messing with Quake 2 engine (various reasons, mostly
non-serious), and hacked on a number of features, most recently:
expanding the map size (now ~98304 inches, or 8192 ft, or 1.55 mi);
adding "drivable vehicles" (technically, they are neither drivable nor
vehicles, but nevermind this...).
prior additions:
support for shadering;
real-time stencil lighting/shadows;
rigid-body physics;
...
nevermind that it still mostly looks and behaves like Q2 at present, and
infact a lot of content was re-added from Q1 as well, ...
>> Java is one of those languages:
>> one hears about it enough, but where is the code?...
>
> Java's strongest constituency is bespoke enterprise software, which
> typically never leaves the organisation for which it was developed.
>
> You may as well ask where all the COBOL or RPG-III code is.
>
yes, ok.
Robert Maas, http://tinyurl.com/uh3t
> Your understanding is wrong.
> Open source is that the customer gets to see the source.
> Not that he gets it for free.
Um, whether the customer pays the software company for the
software, and whether the software company pays the programmers for
their labor, are two different matters. It's possible that
programmers might work for free, and then the organization will
charge customers a fee for packaging and distributing the result of
their labors.
Are you aware of *any* company (or other organization) that pays
programmers to contribute their individual labors to open-source
software projects? If so, I'd like to apply for such *paid* work on
such a project. I'm reasonably competant in Lisp, Java, and PHP, so
I'd be of value in a project using any of those languages.
> WARNING: This product warps space and time in its vicinity.
If the product is software, then the whole product probably fits on
a single USB flashdrive, which weighs less than an ounce, and hence
the amount of space-time warp predicted by general relativity is so
small as to be unmeasurable against instrument noise. If you can
show me a peer-reviewed article in a respectable scientific journal
such as SCIENCE, where the space-time warp of a single USB
flashdrive has been confirmed by direct measurements, I would be
willing to retract this paragraph.
Pascal J. Bourguignon
>> > It's my understanding that open source is vounteer, pro bono, no pay for work.
>> From: p...@informatimago.com (Pascal J. Bourguignon)
>> Your understanding is wrong.
>> Open source is that the customer gets to see the source.
>> Not that he gets it for free.
>
> Um, whether the customer pays the software company for the
> software, and whether the software company pays the programmers for
> their labor, are two different matters. It's possible that
> programmers might work for free, and then the organization will
> charge customers a fee for packaging and distributing the result of
> their labors.
>
> Are you aware of *any* company (or other organization) that pays
> programmers to contribute their individual labors to open-source
> software projects? If so, I'd like to apply for such *paid* work on
> such a project. I'm reasonably competant in Lisp, Java, and PHP, so
> I'd be of value in a project using any of those languages.
It happens. I've had one paid contract to write a GPL'ed software
module once. There are a lot of programmers who are paid to work on
other open source software.
>> WARNING: This product warps space and time in its vicinity.
>
> If the product is software, then the whole product probably fits on
> a single USB flashdrive, which weighs less than an ounce, and hence
> the amount of space-time warp predicted by general relativity is so
> small as to be unmeasurable against instrument noise.
But it still exists.
> If you can
> show me a peer-reviewed article in a respectable scientific journal
> such as SCIENCE, where the space-time warp of a single USB
> flashdrive has been confirmed by direct measurements, I would be
> willing to retract this paragraph.
No need to retract. It's even worse: a memory that is empty (all
zero) weights less than a memory that is filled, because a filled
memory is in a higher state of energy. The worse part is that the
weight of the bits is even millions of order of magnitude less than
the weight of the USB or whatever device, but it still has its effect
on space wrapping, as unmeasurable as it is.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"You question the worthiness of my code? I should kill you where you
stand!"
stan
>> > It's my understanding that open source is vounteer, pro bono, no pay for work.
>> From: p...@informatimago.com (Pascal J. Bourguignon)
>> Your understanding is wrong.
>> Open source is that the customer gets to see the source.
>> Not that he gets it for free.
>
> Um, whether the customer pays the software company for the
> software, and whether the software company pays the programmers for
> their labor, are two different matters. It's possible that
> programmers might work for free, and then the organization will
> charge customers a fee for packaging and distributing the result of
> their labors.
>
> Are you aware of *any* company (or other organization) that pays
> programmers to contribute their individual labors to open-source
> software projects? If so, I'd like to apply for such *paid* work on
> such a project. I'm reasonably competant in Lisp, Java, and PHP, so
> I'd be of value in a project using any of those languages.
Red Hat, IBM, HP, and Novel come to mind. Wait, I forgot the FSF.
BGB / cr88192
"Pascal J. Bourguignon" <p...@informatimago.com> wrote in message
news:874onhq...@hubble.informatimago.com...
and with enough bits, space can bend and stretch and be torn open much as
something else is, well, torn open...
and one can stare deeply into the bowels of the universe, so much from
little more than seeming bits, a single image of what is possible...
and one can look into the chasm of darkness, and the sights contained
therein, and then they can exclaim "OMG WTF! I can see forever!...".
Nobody
> 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?
Modern C compilers for all but the very simplest microcontrollers
tend to follow the C standards quite faithfully. Not to the extent that
you can't find deviations, but to the extent that you don't need to
re-work real-world C code for the sake of the compiler.
Where C code written for such systems uses non-standard features, it's
more likely to be because it's appropriate to do so (e.g. because you need
to do things which aren't covered by the standard, or because the
extensions offer significant performance benefits) than because the
compiler forces you to do so.
Colin Paul Gloster
|-------------------------------------------------------------------------|
|"[..] |
| |
|my reasons for using C are varried, although, part of it may be that [..]|
|[..], 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, ...). |
| |
|[..]" |
|-------------------------------------------------------------------------|
Hi!
How and why do you use relection in C?
With kind regards,
Colin Paul Gloster
BGB / cr88192
"Colin Paul Gloster" <Colin_Pau...@ACM.org> wrote in message
news:alpine.LNX.2.00.0...@Bluewhite64.example.net...
how:
piles and piles of code implementing it (this is hardly a small piece of
code);
some use of API's like ToolHlp, DbgHlp, ... (these are provided by Windows
to help implement debuggers). (much of this has Linux analogues, many via
libdl and extensions, ..., but keeping the Linux port alive and well has
been, well, lacking...).
customized in-memory linking code, a custom DLL loader and an x86
interpreter;
a database to manage metadata (shared variable, function, and type
declarations, ...);
an dynamic C cimpiler (more needed for eval and dynamic loading, not so much
for reflection, but it does have uses getting data loaded into the DB);
...
of note, machine code, and plain compiled C, does not, in itself, contain
sufficient information to allow for reflection, rather, it requires a whole
lot of "support machinery" which serves in part to gather and build this
information, and a lot of dynamic code generation to actually be able to
make use of it for anything.
for example, one can realize after writing a C compiler that, for its
internal operation, it generates piles of useful information, but nearly all
of this is lost with the generated code.
a database was then used to capture some of this data, so that data can be
mined from any code or headers which pass through this compiler (going
further, I eventually ended up adding a "dummy mode" to the compiler upper
end, which basically mines info but does not bother generating any code).
the info in the database is then used in conjunction with information in the
run-time linker, mostly to allow accessing variables, dynamically calling
functions, ... (basically, I can do something sort of like the LISP-style
'apply' with C function pointers, including with dynamically-typed
arguments, given limited static<->dynamic auto-marshalling exists).
a downside:
I am more recently using MSVC for building, and this strips symbols/... from
produced PE/COFF images, which hurts the ability of my dynamic code to
access any "non-exported" statically-compiled+linked code (say, in DLL's),
however, in practice this has not hurt too badly (some of this could be
helped if info from the PDB files were used, and it were required that code
always be built with debugging options, but given in MSVC this breaks
optimization, I have not been willing to generally accept this cost).
(when I was building with GCC, it left symbol info in the produced PE/COFF
images, and I would mine this info as well).
another downside:
dynamic C compilation seems nicer in theory, as it can be noted that C does
not compiler "instantly" (nor is my compiler entirely bug-free), which
someone hurts my motivation to compiler the C code at run-time (although,
dependency tracking and object-file caching does help here, since it can
limit re-compiles mostly to dependency-check failures...).
the result is that I end up doing a lot of dynamically generated code in
ASM, which is not a good option either, and I currently lack any good
"middle of the road" language (although, I had considered a wide range of
options, including allowing a C variant which was relaxed some and able to
"see" all of the declarations in the metadata DB without need for explicit
declaration or import, hence "header-free", ...).
similarly, the effort has not been extended to cover C++ for various reasons
(for example, MSVC and GCC have different ABIs, and my framework yet still
another ABI, ...).
(now consider that there is a half-assed Java implementation in the mix,
...).
and, further:
although it is possible to patch functions at runtime, this is ill-advised
with any statically compiled code (EXE and DLL images), since there is
little to say that the patch will actually effect said static code, or that
this patching will not instead crash the statically-compiled app. there are
also some edge cases where this patch will not be properly updated (say if
function pointers exist to the pre-patch version).
a workaround exists, however:
it requires being explicit about patchable functions (kind of defeats the
purpose of patching);
it requires compiling patchable code via my compiler;
the same effect is easily enough done in static land via specialized use of
function pointers (or via COM interfaces).
why:
all this is a harder issue...
sadly, I have since noted that there are many cheaper and simpler ways to do
nearly everything I have done, giving me doubts at times as to whether this
all was a worthwhile effort...
after all, one can hard-code nearly any of this, or address many of these
cases though special-purpose functions or by doing (generally terrible)
things with pointers, ...
I am left also thinking that maybe had all this actually been "designed"
(rather than hacked and extended in a piecewise manner), a much simpler
piece of technology could have addressed all these uses, ...
in some ways, it is sort of like .NET without the bytecode.
(and, hence, no direct binary compatibility between Win32/Linux
x86/Win64/Linux x86-64... or at least apart from using the interpreter...).
any what if one wants interpretation or bytecode, well then I have an
interpreter, which in turn does x86 (actually, this uses a POSIX-derived set
of APIs, and supports multiple processes, sockets, shared memory, ..., but
uses PE/COFF rather than ELF or similar...).
and, in turn, the world visible from the interpreter is not too much
different from that I tried to escape, as, once again, it is largely without
reflection or high-level abilities (although, these could be added as
APIs...).
but, nearly all of my stuff does not work cleanly between disjoint address
spaces, which is, lame...
(although, eval would not be difficult to pull off, since it would just
require sending the object over to the interpreter and linking it there).
instead I am left considering the possibility of something like DCOM, which
is something I initially terribly wanted to avoid...
Ed Prochak
wrote:
> Thad Smith <ThadSm...@acm.org> wrote:
> > jacob navia wrote:
> > >http://cacm.acm.org/magazines/2009/5/24646-api-design-matters/fulltext
>
> > > Communications of the ACM rarely bring something practical.
> > > This is a good exception.
>
> > > It is a good article about API design, and the problems of bad APIs.
> > Agreed. I plan to distribute the link to others at work. It makes
>
> A good API emerges from iteration. You really can't know how to make a new
> API work for you until you've used it in various situations. Tweak, use,
> tweak use. Sometimes after two or three iterations you have a really solid
> design, sometimes you need more. A couple of the authors suggestions in that
> paper reflect this dilemmea, with the vain suggestions about documentation
> and separating the caller from implementor.
>
> Iteration is extremely hard to accomplish in a commercial environment with
> other engineers because re-writing code is usually frowned upon, especially
> once others have begun using the interface. (Thus if you separate caller
> from implementor you'll never get the opportunity to change the API; and
> it's foolish to think the first try will be even remotely optimal.)
The rule I try to follow is based somewhat on hardware development.:
throw away the prototype!
IOW, your first iteration is seldom optimal. As long as the project
manager understands that, you are okay.
Ed