[kpj at sics.se: Re: Arduino frustrations: C is not a higher-order language, and timing is not an optimization]
Kragen Javier Sitaker
kragen at canonical.org
Tue Jan 3 01:52:06 EST 2012
----- 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
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,
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.
----- End forwarded message -----
More information about the Kragen-discuss