[kpj at sics.se: Re: Arduino frustrations: C is not a higher-order language, and timing is not an optimization]

[Kragen Javier Sitaker]

----- Forwarded message from KPJ <kpj at sics.se> -----

Date: Mon, 2 Jan 2012 12:24:59 +0100
From: KPJ <kpj at sics.se>
To: Kragen Javier Sitaker <kragen at canonical.org>
Cc: kpj at sics.se
Subject: Re: Arduino frustrations: C is not a higher-order language,
	and timing is not an optimization
User-Agent: SquirrelMail/1.4.20

Hello.

Kragen Javier Sitaker <kragen at canonical.org> wrote:
|
|- The heap grows up and the stack grows down, and there's no memory
|    protection.  Even if you don't use recursion, there's no way to
|    get help from the compiler computing your maximum stack depth,
|    so the way you discover you've malloced too much memory is that
|    your stack corrupts some malloced block, or vice versa.

This is not inherently a problem with higher-vs-lower level language,
as such.

The Digital PDP-10 computer handled this problem in the 1970s and 1980s
by simply re-defining "push" and "pop" to check for stack pointer over-
and underflow. They made this in hardware, but this can of course be
done in software and/or in the compiler as well.

If the stack pointer is replaced by a 2-tuple <-size,pointer> and the
"-size" becomes non-negative, this implies a stack overflow in a "push".

If the "pointer" becomes out of bounds (meaning less than STACK-1 or
greater than STACK+size depending on the implementation, where STACK is
the "beginning of the stack"), this implies a stack underflow.

If your system supports alloca() and friends, they must also be changed
for this scheme to work.

The problem with Arduino and other non-computers is that one must think
in assembler, using C as the "hardware independent assembler". C++ is
not an option due to the inherent code bloat of most C++ compilers. YMMV.

  /kpj


----- End forwarded message -----