API Design
jacob navia
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.
jacob
Malcolm McLean
> 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.
>
One handy hint is to always provide a hook pointer with a callback. (So
qsort should be
void sort(void *data, int N, size_t width, int (*compfunc)(void *, void *,
void *ptr), void *ptr);
ptr can be null, or it can be used to hang off arbitary data used by the
comparator.
Richard
It was an interesting read. I'm somewhat astonished, however, that the
regs haven't shut this thread down as "off topic". C doesn't have C
related APIs apparently.
--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
Thad Smith
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
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
BGB / cr88192
yeah, it is difficult to get API design down well...
usually I just make use of lots of "rules of thumb" I have learned from
prior experiences, and will often find an API which works well, and attempt
to use it as a template.
granted, some things are better, and other things are not as good.
for example, at a time I believed strongly in strict opaqueness, and also
really liked the design of OpenGL.
I then used it as the basis of the design of a physics library, and I
suspect that over the past several years, this opaqueness-centric API design
has probably done more harm than good.
for example, I had found that, in the choice of handles, it really does not
make much practical difference if the handles are integers or opaque
pointers, and infact the opaque-pointer practice may be better in the
general case, mostly since for any integer handle, one needs to know its
contexts, wheras pointers can be, inherently, self-identifying.
so, for an API based on integers, one may have to first "bind" a context,
and then "bind" an object, and then be able to perform manipulations. this
then makes a further issue, as then one needs to use a thread-local
variable, ... to keep track of these bindings, ...
OTOH, with a pointer, one would only need the pointer and the API call.
at the time, I had thought, "well, a pointer would be a problem if, say, a
network or disjoint address spaces is involved". though this would seem to
make intuitive sense (since an integer can be passed as-is, a pointer is
inherrently address-space specific, ...), I have found that in practice,
this is not such an issue:
marshalling opaque pointers is really not all that big of an issue, so long
as they don't necessarily need to be addressable. in fact, the "pointer" can
simply address an otherwise inaccessible region of memory, and used
essentially as an integer handle internally, ...
but, the gain of the pointer is that the "value" is inherently unique (even
if not the same in the multi-node case...), which in many cases buys far
more usability than it costs (the API can "just know" what context owns a
given object, and so the context need not be supplied).
this is not to say that integer handles are bad and pointers are good, only
that such a subtle issue can be hard to know up-front, and some bad choices
can lead to an API where using it is a lot more painful than it actually
need be.
likewise, shared structs are not quite as evil as I had once believed,
although granted, a shared struct is still something difficult to get right
(and, in general, I am still more a fan of getters/setters than I am of
having direct access to fields, ...).
however, if the struct itself is standardized, and more serves simply as a
way of moving data, it may well still be a better option than API calls with
piles of arguments, or long convoluted chains of getter and setter calls
(and having to worry about some particular getters/setters themselves either
involving expensive computations or otherwise changing state in ways which
impact subsequent calls, ...).
or, potentially, the use of adjustable unit conversions (which just happen
to be part of the global state), ...
so, it can be hard to get decisions right in retrospect even for ones' own
use cases sometimes, much less for the general case...
but I have made an observation: often the more effort I put into "designing"
something, the more likely it is to have some notable design flaw later on.
hence, in general, I have found it often works better to try to find a
design that already works well enough, and attempt to "adapt" the design to
work in the new context, than it is to design something clean (and have it
far more likely to turn out badly in the end...). (likewise, simpler is
often better, so better to design for the simple cases first, ...).
although, rigid adherence to a particular set of methodologies for an
otherwise unrelated piece of technology seems to not turn out so well
either, for example, OpenGL is OpenGL, but OpenGL is not necessarily the
perfect design template for things like Physics, GUI code, OO facilities,
...
even though the names and conventions may all look almost the same (one
creating objects and completing tasks via Begin and End pairs, ...), the
more subtle issue, that the task is inherently very different and not
necessarily a good fit for this API design style, may well impede subsequent
usability... (and, it may well make sense to have the "objects", of all
things, be the focus of attention...).
it is almost no better than those API designs where the designer sees a
problem and declares to themselves "it is all a simple matter of organizing
the class heirarchy" (as much as I despise this approach as well). "it is
all abstract properties, getters, and setters" may well not be much
better...
there are no silver bullets it seems...
or such...
> jacob
Gareth Owen
> It was an interesting read. I'm somewhat astonished, however, that the
> regs haven't shut this thread down as "off topic". C doesn't have C
> related APIs apparently.
Its possible you've won a small victory. But crowing over it will not
be helpful.
Richard
Gareth Owen
>> Its possible you've won a small victory. But crowing over it will not
>> be helpful.
>
> That is not crowing.
Teasing, taunting, baiting, inciting, challenging. Whatever.
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
Richard
Incorrect.
All of that is people claiming that a POSIX Api function call is not C.
Lets keep it real.
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).
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
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.
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).
stan
> Marco a �crit :
>>
>> I respectfully disagree that this belongs in the C language. The C
>> 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.
>
> 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.
So code it up. If you're correct then the malloc family will fade
away. Debate seems pointless, doesn't it?
Personally I doubt there is a one size fits all solution. I can
imagine cases where I would never consider GC due to overkill. But I
can also imagine cases where it would be handy if nothing else but for
rapid prototyping stuff.
There seem to be two distinct and intractable camps involved. The
no-GC crowd is never going to code up a GC system (understandably) and
the GC crowd hasn't done so yet. It sounds a little too blunt to me
but maybe it's time to put up or shut up.
If GC really is a near silver bullet, why isn't it done yet? If it's
as simple as a library then it doesn't have to wait for anything or
anyone. Seems like a great candidate for either a commercial solution
or open source. Improved productivity with fewer errors and no
performance loss would certainly be of value to someone.
Keith Thompson
[...]
> There seem to be two distinct and intractable camps involved. The
> no-GC crowd is never going to code up a GC system (understandably) and
> the GC crowd hasn't done so yet. It sounds a little too blunt to me
> but maybe it's time to put up or shut up.
>
> If GC really is a near silver bullet, why isn't it done yet? If it's
> as simple as a library then it doesn't have to wait for anything or
> anyone. Seems like a great candidate for either a commercial solution
> or open source. Improved productivity with fewer errors and no
> performance loss would certainly be of value to someone.
GC has been implemented. See, for example,
<http://www.hpl.hp.com/personal/Hans_Boehm/gc/>.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
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.
BGB / cr88192
"Keith Thompson" <ks...@mib.org> wrote in message
news:lnr5qme...@nuthaus.mib.org...
> stan <smo...@exis.net> writes:
> [...]
>> There seem to be two distinct and intractable camps involved. The
>> no-GC crowd is never going to code up a GC system (understandably) and
>> the GC crowd hasn't done so yet. It sounds a little too blunt to me
>> but maybe it's time to put up or shut up.
>>
>> If GC really is a near silver bullet, why isn't it done yet? If it's
>> as simple as a library then it doesn't have to wait for anything or
>> anyone. Seems like a great candidate for either a commercial solution
>> or open source. Improved productivity with fewer errors and no
>> performance loss would certainly be of value to someone.
>
> GC has been implemented. See, for example,
> <http://www.hpl.hp.com/personal/Hans_Boehm/gc/>.
>
yep.
Boehm is popular for implementing many VM's, such as Mono and GCJ.
in my case, I have my own GC, and differs in some of the details from Boehm
(the most notable being that mine does types tagging, whereas Boehm leaves
it up to the frontend to keep track of types).
similarly, AFAIK, Boehm has a higher per-object overhead for small objects
(in my case it is 8 or 16 bytes, depending on needed alignment, and size is
padded up to a multiple of 16 bytes).
however, I suspect Boehm does have better reliability and performance.
so, I guess, viewed another way:
Boehm works really well as a GC'ed malloc replacement;
it is not necessarily as good as a more specialized GC.
where it is used, such as in Mono and GCJ, I don't exactly think they have
much reason to worry about per-object overhead (errm... because there are no
"small" objects...).
well, for those few who have gazed into Mono's internals, well, they are not
exactly, pretty...
I guess, some could debate this, but this is mostly my opinion (actually,
IMO, Mono's internals make the Quake engine look pretty, and this much is
scary... as IMO the Quake engine is a tangled mess...).
but, alas, both projects seem to work well enough, so that much is good...
mine was designed, of course, to assume that, say, 8-24 byte objects would
be common.
mine also supports special "cons cell" objects, which take 8 or 16 bytes
(depending on word size).
this doesn't matter so much if, say, the first thing the VM is to do is
create an object with a 32 or 48 byte header and maybe 128+ bytes of
payload.
granted, one can think at a higher level of abstraction, and realize that
this larger object may be infact more memory dense than, say, an structure
made out of cons cells and symbols located all over the place (and, just the
same, sometimes nastier code is both more efficient and easier to work
with...).
in this case, Boehm is probably a better choice...
stan
> stan <smo...@exis.net> writes:
> [...]
>> There seem to be two distinct and intractable camps involved. The
>> no-GC crowd is never going to code up a GC system (understandably) and
>> the GC crowd hasn't done so yet. It sounds a little too blunt to me
>> but maybe it's time to put up or shut up.
>>
>> If GC really is a near silver bullet, why isn't it done yet? If it's
>> as simple as a library then it doesn't have to wait for anything or
>> anyone. Seems like a great candidate for either a commercial solution
>> or open source. Improved productivity with fewer errors and no
>> performance loss would certainly be of value to someone.
>
> GC has been implemented. See, for example,
><http://www.hpl.hp.com/personal/Hans_Boehm/gc/>.
I'm aware of Boehm; it doesn't really seem to be taking the world by
storm. I don't intend it as a put down but it's not really the easiest
thing to set up. Maybe if it starts to catch on people will improve
the ease of use. If GC was really solving global warming and world
hunger then there would be little need for the endless debate. Boehm
hasn't proved to be the library that meets those needs so far so
either GC claims aren't completely and precisely correct or "THE GC
LIBRARY" (TM) hasn't been written yet.
For the record I've used and have no problems with Boehm's GC lib.
Programming is a never ending series of compromises and contexts
IMHO. Most people in the two camps seem to suffer tunnel vision. GC is
useful in some cases and a problem in others. The truth is that for
most of the cases where GC would be most useful, C may not be the best
language choice. Like the committee trying to design a horse and
produced a camel, I think the committee trying to add higher level
stuff to C already had one crack at it and they produced C++.
Personally I think the best and so far least explored option would be
a hardware memory management system with GC. I've talked to others
about it but right now the money seems to be pushing parallel
stuff.
Just so I can sleep tonight and not have bad dreams about the lack of
thread topicality, I haven't really thought about a possible ISA API
for a hardware solution. I've thought about both in the existing
memory/cache management HW or possibly in the northbridge or bus
management levels but not about the API. Since I'm all but snowed in,
I might just get some eggnog and stoke up the fire!
BGB / cr88192
"stan" <smo...@exis.net> wrote in message news:o2aa07-...@invalid.net...
you don't need GC in the HW...
you don't even really need (high-level) memory-management in the HW.
it would be enough if it were implemented at the OS kernel + C runtime
level, and the implementation could fudge around and make a GC-friendly
malloc.
probably what this would mean would be "decent" OS-level write barriers, ...
as well as a GC which is present in the main C runtime (right alongside
malloc/free).
having to catch a signal and change the page status before returning
(Linux), or perform a query of which ones have been written and reset their
status (Windows), are just kind of lame...
(it is also lame that one doesn't generally know either the exact address
written, or what was written there).
also useful could be to be able to cause any threads which write to these
pages to essentially stall until the page status is changed (similar to
blocking file IO). in this way, a simple mark/sweep, or even a
copy-collector, could be done with C, with no particular added effort (the
copy-collector could work by essentially locking all non-GC access to the
memory until after the GC completes, thus preventing the mutator threads
from being able to see the heap in an intermediate state).
as-is, one either has to use crappy+awkward write barriers, or not bother
(using simply a SW write barrier, but I have seen how well this turns
out...).
the "stall until status change" option would not be too difficult to
implement I would think, since something fairly similar is likely already
needed to implement things like swapfiles, ...
the big problem then would be convincing anyone to do so. their likely
response would be something like "well, you can do it easily enough on your
own", or maybe "the standard doesn't say so, so we are not going to
bother...".
jacob navia
>
> I'm aware of Boehm; it doesn't really seem to be taking the world by
> storm. I don't intend it as a put down but it's not really the easiest
> thing to set up.
With lcc-win there is nothing to setup. And anyway,if you
do not want to recompile it and use a binary library
it is as easy as using any other library. Use the
#include and link with the library.
> Maybe if it starts to catch on people will improve
> the ease of use. If GC was really solving global warming and world
> hunger then there would be little need for the endless debate. Boehm
> hasn't proved to be the library that meets those needs so far so
> either GC claims aren't completely and precisely correct or "THE GC
> LIBRARY" (TM) hasn't been written yet.
>
This is just your opinion. It i widely used, has been ported to
a variety of systems, and there are thousands and thousands
of users. Gcc has adopted it too and distributes it with the
source code of gcc, zs far as I remember.
> For the record I've used and have no problems with Boehm's GC lib.
>
Well, you see?
> Programming is a never ending series of compromises and contexts
> IMHO. Most people in the two camps seem to suffer tunnel vision. GC is
> useful in some cases and a problem in others.
Yes. As everything. Nobody is telling here that is the solution for
all software problems.
> The truth is that for
> most of the cases where GC would be most useful, C may not be the best
> language choice.
Always the same story. C is bad language when you want to program
an application. Look, if you want, so be it. Please go to another
discussion group then.
Kaz Kylheku
> Keith Thompson wrote:
>
>> stan <smo...@exis.net> writes:
>> [...]
>>> There seem to be two distinct and intractable camps involved. The
>>> no-GC crowd is never going to code up a GC system (understandably) and
>>> the GC crowd hasn't done so yet. It sounds a little too blunt to me
>>> but maybe it's time to put up or shut up.
>>>
>>> If GC really is a near silver bullet, why isn't it done yet? If it's
>>> as simple as a library then it doesn't have to wait for anything or
>>> anyone. Seems like a great candidate for either a commercial solution
>>> or open source. Improved productivity with fewer errors and no
>>> performance loss would certainly be of value to someone.
>>
>> GC has been implemented. See, for example,
>><http://www.hpl.hp.com/personal/Hans_Boehm/gc/>.
>
> I'm aware of Boehm;
Yes, you are---now. Your earlier posting /clearly/ shows that you
are not aware that GC exists for C programs.
> it doesn't really seem to be taking the world by
> storm.
``Not taking the world by storm'' is not nearly the same thing
as ``not done yet''.
> I don't intend it as a put down but it's not really the easiest
> thing to set up.
$ ./configure
$ make ; make install
> For the record I've used and have no problems with Boehm's GC lib.
Yet, ``[gc] isn't done yet''. Hmm!
Keith Thompson
> stan a écrit :
[...]
>> The truth is that for
>> most of the cases where GC would be most useful, C may not be the best
>> language choice.
>
> Always the same story. C is bad language when you want to program
> an application. Look, if you want, so be it. Please go to another
> discussion group then.
jacob, I'm sure that you understand the difference between "C
may not be the best language choice" and "C is [a] bad language".
Please consider demonstrating that knowledge next time you post.
stan
> stan a �crit :
>>
>> I'm aware of Boehm; it doesn't really seem to be taking the world by
>> storm. I don't intend it as a put down but it's not really the easiest
>> thing to set up.
>
> With lcc-win there is nothing to setup. And anyway,if you
> do not want to recompile it and use a binary library
> it is as easy as using any other library. Use the
> #include and link with the library.
My last brush with lcc was some time ago; I didn't know it had GC
until one of your earlier posts. I don't know anyone who is using
lcc-win but I admit that doesn't mean there aren't any.
>> Maybe if it starts to catch on people will improve
>> the ease of use. If GC was really solving global warming and world
>> hunger then there would be little need for the endless debate. Boehm
>> hasn't proved to be the library that meets those needs so far so
>> either GC claims aren't completely and precisely correct or "THE GC
>> LIBRARY" (TM) hasn't been written yet.
>
> This is just your opinion. It i widely used, has been ported to
> a variety of systems, and there are thousands and thousands
> of users. Gcc has adopted it too and distributes it with the
> source code of gcc, zs far as I remember.
Where do those numbers come from? Admittedly, I don't personally know
every developer but in my small world I don't know any C developer who
is actively seeking GC for any of their current projects.
>> For the record I've used and have no problems with Boehm's GC lib.
>>
> Well, you see?
Not really. I also regularly work without GC and I don't feel I need
it for everything I do nor do I see a need to add it to the language.
>> Programming is a never ending series of compromises and contexts
>> IMHO. Most people in the two camps seem to suffer tunnel vision. GC is
>> useful in some cases and a problem in others.
>
> Yes. As everything. Nobody is telling here that is the solution for
> all software problems.
>
>> The truth is that for
>> most of the cases where GC would be most useful, C may not be the best
>> language choice.
>
> Always the same story. C is bad language when you want to program
> an application. Look, if you want, so be it. Please go to another
> discussion group then.
Do you want everyone who disagrees with you to leave or just me?
Your request notwithstanding, I probably won't hang around clc all
that long. I've been coming and going for a long time and things don't
seem to really change much. The signal to noise is not really all that
good and it takes too much time and effort to weed through to find
anything useful.
As for GC I'm agnostic; I don't find much in common with the "never" or
the "must have" camps. But I'm unconvinced it needs to be added to the
C language. I have no reasonable doubt that C will not fade away
rapidly simply because it lacks GC. So far the arguments in this
thread haven't been convincing.
stan
> On 2009-12-23, stan <smo...@exis.net> wrote:
>> Keith Thompson wrote:
<snip>
>>> GC has been implemented. See, for example,
>>><http://www.hpl.hp.com/personal/Hans_Boehm/gc/>.
>>
>> I'm aware of Boehm;
>
> Yes, you are---now. Your earlier posting /clearly/ shows that you
> are not aware that GC exists for C programs.
Your guess would be wrong about my prior experience. The first time I
recall hearing about it was on clc++ from James Kanze. I don't
recall exactly when that happened, but it wasn't recent.
>> it doesn't really seem to be taking the world by
>> storm.
>
> ``Not taking the world by storm'' is not nearly the same thing
> as ``not done yet''.
I seem to have lost you. The sentence was about Boehm's GC not taking
the C programmer world by storm.
While it has drifted way off the topic this thread was about API's and
the context of the statement was about developing a GC library. Since
Boehm's GC currently exists and yet this thread included developing GC
in a library a reasonable person could conclude that the status quo
isn't the "ULTIMATE GC LIBRARY". From there "not done yet" isn't much
of a stretch.
So we have:
1. Boehm - not taking the world by storm.
2. ULTIMATE GC library - not done yet.
Better?
>> I don't intend it as a put down but it's not really the easiest
>> thing to set up.
>
> $ ./configure
> $ make ; make install
>
>> For the record I've used and have no problems with Boehm's GC lib.
>
> Yet, ``[gc] isn't done yet''. Hmm!
I won't argue, try to explain myself, or try to convince you. I don't
believe what I said was all that hard to understand, but I'll give you
the last word if you feel to need to interpret further.
For my money I've already contributed enough to thread drift.
Keith Thompson
Kaz wasn't the only one who misunderstood what you wrote. And yes,
I'd say it's quite a stretch.
It seemed perfectly clear to me that your phrase "not done yet"
implied that GC had not been implemented for C. My own response,
citing Boehm, was simply intended to refute that implication.
Apparently that wasn't what you meant, but since there had been no
mention of an "ULTIMATE GC LIBRARY" (I question the existence,
even potentially, of an "ULTIMATE *anything* LIBRARY"), and
since you hadn't indicated that you knew about Boehm, I think our
interpretation was a reasonable one.
Again, here's what you wrote (taken slightly out of context, but I
don't think that alters the meaning):
The no-GC crowd is never going to code up a GC system
(understandably) and the GC crowd hasn't done so yet.
> So we have:
>
> 1. Boehm - not taking the world by storm.
> 2. ULTIMATE GC library - not done yet.
>
> Better?
Ok. I understand now that you didn't mean to say that GC hasn't
been implemented in (or for) C. But if you'll go back to what
you wrote and re-read it, without making too many assumptions,
I think you'll see why you were misunderstood.
[snip]
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
|-------------------------------------------------------------------------|
|"jacob navia <ja...@nospam.org> writes: |
|> stan a écrit : |
|[...] |
|>> The truth is that for |
|>> most of the cases where GC would be most useful, C may not be the best|
|>> language choice. |
|> |
|> Always the same story. C is bad language when you want to program |
|> an application. Look, if you want, so be it. Please go to another |
|> discussion group then. |
| |
|jacob, I'm sure that you understand the difference between "C |
|may not be the best language choice" and "C is [a] bad language". |
|Please consider demonstrating that knowledge next time you post." |
|-------------------------------------------------------------------------|
Keith Thompson,
Jacob Navia actually posted: "C is bad language when you want to program
an application"
instead of "C is [a] bad language".
Please be fair. Anyhow, C actually is a bad language.
Sincerely,
Colin Paul Gloster
jacob navia
> Anyhow, C actually is a bad language.
>
> Sincerely,
> Colin Paul Gloster
OK. Then
(1) Do not use it
(2) Do not participate in this forum. Use Python/C++/LISP/whetever
What is the point in going to a forum about C and telling people that it is a bad
language?
Just trolling.
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
Colin Paul Gloster
|----------------------------------------------|
|"Colin Paul Gloster a écrit : |
| |
|> Anyhow, C actually is a bad language. |
|> |
|> Sincerely, |
|> Colin Paul Gloster |
| |
|OK. Then |
| |
|(1) Do not use it" |
|----------------------------------------------|
Thanks.
|----------------------------------------------|
|"(2) Do not participate in this forum." |
|----------------------------------------------|
This is an unmoderated forum and I participate.
|----------------------------------------------|
|" Use Python" |
|----------------------------------------------|
No, thanks.
|----------------------------------------------|
|"/C++/" |
|----------------------------------------------|
No, thanks.
|----------------------------------------------|
|"LISP" |
|----------------------------------------------|
No, thanks.
|----------------------------------------------|
|"/whetever |
| |
|What is the point in going to a forum about C"|
|----------------------------------------------|
I have noticed that the thread (which I have begun reading on another
newsgroup) was started only on news:comp.lang.c so I looked at
news:comp.lang.c for contributions which I had missed.
|----------------------------------------------|
|" and telling people that it is a |
|bad |
|language?" |
|----------------------------------------------|
Keith Thompson failed to correctly paraphrase the sentiment
"C is bad language when you want to program
an application"
issued by you. I pointed this out, and I confirmed that the statement
wrongly attributed to you was true anyway. If you really like garbage
collection and really are so naive as to like C, then perhaps you
should read the book "Modern Compiler Implementation in C", which does
not exactly flatter C and which uses garbage collection throughout
(without actually truly compiled and run C code).
Appreciation that something is bad is not the same as not using it
with due care and attention. Using something bad without realizing it
would be even worse.
|----------------------------------------------|
|"Just trolling." |
|----------------------------------------------|
No.
Kenny McCormack
Keith "Kiki" Thompson <ks...@mib.org> wrote:
...
>jacob, I'm sure that you understand the difference between "C
>may not be the best language choice" and "C is [a] bad language".
>Please consider demonstrating that knowledge next time you post.
Technically, you are correct. However, in the language of character
assasination, and particularly, in the context of this newsgroup, the
phrase "X may not be the best" usually translates as "X is bad".
Be honest with yourself. When you hear that sort of phrase is real
life, from people who are not well-disposed towards you, that is the
message that you take from it. Isn't it?
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...
BGB / cr88192
"Kaz Kylheku" <kkyl...@gmail.com> wrote in message
news:200912231...@gmail.com...
> On 2009-12-23, stan <smo...@exis.net> wrote:
>> Keith Thompson wrote:
>>
>>> stan <smo...@exis.net> writes:
>>> [...]
>>>> There seem to be two distinct and intractable camps involved. The
>>>> no-GC crowd is never going to code up a GC system (understandably) and
>>>> the GC crowd hasn't done so yet. It sounds a little too blunt to me
>>>> but maybe it's time to put up or shut up.
>>>>
>>>> If GC really is a near silver bullet, why isn't it done yet? If it's
>>>> as simple as a library then it doesn't have to wait for anything or
>>>> anyone. Seems like a great candidate for either a commercial solution
>>>> or open source. Improved productivity with fewer errors and no
>>>> performance loss would certainly be of value to someone.
>>>
>>> GC has been implemented. See, for example,
>>><http://www.hpl.hp.com/personal/Hans_Boehm/gc/>.
>>
>> I'm aware of Boehm;
>
> Yes, you are---now. Your earlier posting /clearly/ shows that you
> are not aware that GC exists for C programs.
>
well, I guess, one could argue "it doesn't", well, so long as one sticks to
the standard and/or strictly modular practices (note that my definitions of
"modularity" may even deny the ability to use many aspects of the C runtime,
depending on situation and the allowed set of dependencies for a given piece
of code).
>> it doesn't really seem to be taking the world by
>> storm.
>
> ``Not taking the world by storm'' is not nearly the same thing
> as ``not done yet''.
>
>> I don't intend it as a put down but it's not really the easiest
>> thing to set up.
>
> $ ./configure
> $ make ; make install
>
actually, configure is evil, or at least if one happens to develop on
Windows (where configure rarely works even on "blessed" targets such as
Cygwin and MinGW...).
the situation is even worse, if one happens to have MSVC as a build
target...
granted, I have not checked personally if Boehm is set up to build with
MSVC, but then again I have my own GC which works well enough.
FWIW, Makefiles are better IMO, since one can make Makefiles for different
sets of build targets (including MSVC), even despite their drawback of not
being able to automatically probe every little aspect of the system (and
forcing on people the incredible terror of having to actually write
general-purpose code if they hope for portability...).
admittedly, there is no "perfect" solution.
>> For the record I've used and have no problems with Boehm's GC lib.
>
> Yet, ``[gc] isn't done yet''. Hmm!
yep.
Marco
>
> >> The truth is that for
> >> most of the cases where GC would be most useful, C may not be the best
> >> language choice.
> As for GC I'm agnostic; I don't find much in common with the "never" or
> the "must have" camps. But I'm unconvinced it needs to be added to the
> C language. I have no reasonable doubt that C will not fade away
> rapidly simply because it lacks GC. So far the arguments in this
> thread haven't been convincing.
I agree - future ISO C standards do not need to add a bunch of new
features they just need to do some "cleanup" such as security etc.
If someone really needs garbage collection, take a look at the D
programming language.
stan
> stan <smo...@exis.net> writes:
<snip>
> Again, here's what you wrote (taken slightly out of context, but I
> don't think that alters the meaning):
>
> The no-GC crowd is never going to code up a GC system
> (understandably) and the GC crowd hasn't done so yet.
Fair enough.
>> So we have:
>>
>> 1. Boehm - not taking the world by storm.
>> 2. ULTIMATE GC library - not done yet.
>>
>> Better?
>
> Ok. I understand now that you didn't mean to say that GC hasn't
> been implemented in (or for) C. But if you'll go back to what
> you wrote and re-read it, without making too many assumptions,
> I think you'll see why you were misunderstood.
I do understand. I also think I've provided another data point in
another too long and wandering thread so I'll just let this rest.
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