----- Forwarded message from Kragen Javier Sitaker <[email protected]> -----
Date: Mon, 2 Jan 2012 11:17:19 -0500 From: Kragen Javier Sitaker <[email protected]> To: KPJ <[email protected]> Subject: Re: Arduino frustrations: C is not a higher-order language, and timing is not an optimization User-Agent: Mutt/1.5.20 (2009-06-14) On Mon, Jan 02, 2012 at 12:24:59PM +0100, KPJ wrote: > Hello. Hi. May I forward your response to kragen-discuss? > Kragen Javier Sitaker <[email protected]> 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. Agreed. (Although one way to avoid it is to use a language that doesn't have recursive subroutines.) > 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. As I understand it, this is how Chez Scheme handles call/cc and thus multithreading: rather than allocate each thread a giant region of virtual memory for its stack, check on call and return for overflow and underflow of the current stack "segment", respectively allocating a new segment or moving the stack pointer to the parent stack segment if so. Dybvig probably has PUSHJ tattooed on his scalp. The problem with this approach is, on the Arduino, what are you going to do if you get a stack overflow? Flash an LED with a stack trace in Morse code? I really want to prove safety at compile-time. > 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. C++ seems to work okay on the Arduino in practice, or at least no worse than C, due to its practice of not charging you for what you don't use: exceptions, RTTI, virtual method dispatch, static constructors, etc. It's true that C++ compilers often do a bad job of optimizing template-generated code; is that what you have in mind? Krgen ----- End forwarded message ----- -- To unsubscribe: http://lists.canonical.org/mailman/listinfo/kragen-discuss
