Re: Parser Generators for Multiple Protocols in an Embedded Device

iddw@hotmail.com (Dave Hansen)
3 May 2002 16:02:19 -0400

          From comp.compilers

Related articles
Parser Generators for Multiple Protocols in an Embedded Device nou.dadoun@polycom.com (2002-04-23)
Re: Parser Generators for Multiple Protocols in an Embedded Device k.prasad@attbi.com (Kamal R. Prasad) (2002-04-29)
Re: Parser Generators for Multiple Protocols in an Embedded Device haberg@matematik.su.se (2002-05-01)
Re: Parser Generators for Multiple Protocols in an Embedded Device iddw@hotmail.com (2002-05-03)
Re: Parser Generators for Multiple Protocols in an Embedded Device joachim.durchholz@munich.netsurf.de (Joachim Durchholz) (2002-05-03)
Re: Parser Generators for Multiple Protocols in an Embedded Device haberg@matematik.su.se (2002-05-04)
| List of all articles for this month |

From: iddw@hotmail.com (Dave Hansen)
Newsgroups: comp.compilers,comp.lang.misc
Date: 3 May 2002 16:02:19 -0400
Organization: Compilers Central
References: 02-04-133 02-04-154 02-05-006
Keywords: design
Posted-Date: 03 May 2002 16:02:19 EDT

Apologies if this is drifting too far off-topic...


On 1 May 2002 23:19:22 -0400, haberg@matematik.su.se (Hans Aberg)
wrote:


[...]


>There is an "embedded C++", and Bjarne Stroustrup has announced that
>for the next revision of C++, he wants that, if possible, to be merged
>with C++. -- Or so I recall; see the newsgroup comp.std.c++, first
>article in the thread "C++0x" one or two years ago year.


EC++ is an attempt to make C++ more appropriate for developing
embedded systems. It's basically standard C++ with some of the more
complicated and/or useful bits removed. The goal was noble, but
(IMHO) it degenerated into "here's a feature that can be abused, so
we'll get rid of it."


"Merging" it with C++ doesn't seem practical. It's a subset, nothing
really new.


[...]


>As for embedded programming, one can note that memory has doubled
>every year: It is really the mass-consumption PC's and the need for
>IC's to generate less heat that drives this development. So it should
>apply to embedded programming as well. This means that if it takes
>(say) 50 MB to implement a mini-OS with a WWW server, and your average
>bread machine some years ago used 50 kB, it will only ten years minus
>some for your average bread-machine to have a WWW server. By then,
>this will be a cheap solution, as other physical controls (like
>buttons) need not be implemented (there is already a standard for
>hooking up devises to the Internet via the electrical cord, I recall).
>
>It means that also embedded programming, as memory becomes plenty, will
>make use of high level programming techniques.


"Embedded Systems" is probably the least specific term in all of
computer science. I personally have worked on an embedded system that
required more than 3 times the memory of your "WWW server" example.
The code was pretty much standard C++ (as close as the available
compiler could get us, anyway).


I just finished another project a few weeks back with less than 1K of
program memory, using less than 32 bytes of RAM. This project used
mostly standard C (as close as the available compiler could get us,
anyway).


There "embedded systems" in use today that are much larger than my
first example. There are also some much smaller than my second.


My point is that "high level programming techniques" are already used
where they are appropropriate. And there are applications where they
will *never* be used. In the latter application, a savings of $0.10
in the cost of components could mean more than $100,000 per year. If
memory becomes cheaper, those applications will choose the cost
savings rather than the excess memory.


[...]


>[50MB? Are you nuts? The QNX demo has OS TCP/IP stack, GUI, web
>browser and server, and fits on a floppy. There are similarly small
>mini-Linux systems. We could have web toasters now, but I wouldn't
>want to use one. See
>http://www.nytimes.com/2002/04/28/technology/28GIZM.html (free
>registration needed.) -John]


The QNX demo is super-slick, but relies heavily on compression, and
last I knew required 6 MB of RAM to set up a file system to expand
into. Still much less than 50 MB, though...


Regards,


                                                              -=Dave
[It's on-topic so long as it has some bearing on how you'd build
compilers. There's been tons of work on embedded and memory-limited
systems, but much of it seems known only to the workers down in the
trenches. -John]



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.