API Design

[BGB / cr88192]

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.

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.«

(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 :

Look, C++ is the best language in the world and C is a old shit.

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.

 

[jacob navia]

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.

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.

 

[Ian Collins]

Ian Collins a écrit :

Where's the quotes I asked for?

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?

 

[Flash Gordon]

Ian Collins a écrit :

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.

 

[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]

gwowen a écrit :

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 :







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.

 

[Flash Gordon]

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.

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).

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!

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.

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.

 

[Stefan Ram]

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.

Yes. C as a low-level implementation language for
programmers who can be trusted (»trust the programmer«)
should be chosen whenever appropriate, e.g., as a system
programming language or as a language to implement garbage
collectors, languages or other domain-independent tools.

The sad thing only is, when it is being chosen as
an application programming language and with programmers
who have not yet reached the trustable level, or as
a teaching language, when there is not really the time
to teach what is needed to become productive in C.

 

[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

 

[robertwessel2]

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]

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.

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.

 

[Nobody]

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]

I think you'll find that the history of GC *easily* predates the PDP series.
Start here:

http://www.cs.kent.ac.uk/people/staff/rej/gcbib/gcbibA.html

Garbage collection is as old as LISP, AFAIK. That is 1960 or 1961.
Notably, IPL was lacking a garbage collector.

 

[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.

 

[BGB / cr88192]

There is a lot still done in C...

yep, including in apps...

Probably especially libraries and code for compilers.

granted.



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?...

We have a fair bit which we sell.

ok.



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?...

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...

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...

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.



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...

<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, ...

 

[BGB / cr88192]

For 16kB, GC isn't out of the question, particularly for restricted cases
(e.g. strings; GC is somewhat simpler when you don't have to worry about
circular references).

yep, and GC need not be some piece of esoteric machinery which one gives
over all their memory alocation to and hence-forth never use manual handling
again. this is merely one form of GC.


one could instead define it more loosely, as a methodology where the code
responsible for creating objects is not necessarily also responsible for
freeing them...

a simple example would be that, for example, a piece of code uses items of a
given type, and when fetching an item will mark it;
more so, the overall process is handled in units, so that if an item it not
touched in a given unit, we can know it is no longer needed (there is no
external persistent state);
so, at the start of the unit, all marks are cleared, and during operation
the units are marked;
at the end of the unit, any items which were not marked are released (or
marked free).

this can be considered a form of GC, but with almost no overhead for these
sorts of use cases, and leads to simpler and more efficient code than would
be the case if the items were tracked directly.

likewise for fixed-size rotating spaces or buffers, or even simply clearing
or discarding all the contents of a given "heap", ...


so, it depends a lot on ones' definitions and specific situation...

 

[robertwessel2]

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.

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