On Dec 5, 2013 11:32 PM, "Chris Barker" <[email protected]> wrote: > > On Thu, Dec 5, 2013 at 11:27 PM, geremy condra <[email protected]> wrote: >> >> > very cool! >> >> Hmm, dunno about this. >> >> His stated goal is to match Python's grammar, but it's possible to conform completely to Python's grammar and still not be very much like python. In particular, adopting C integer semantics is pretty wild. I can't think of a sizeable body of Python code I would count on to handle that gracefully. > > well, I think this is about being able to write python code specifically to drive this device -- much less about porting other code to it. And I think the C integers are optional. But as a proof of concept, Cython lets you optionally use straight C ints, and it's very useful.
I don't think this is optional behavior. At the least it can't interoperate between the two modes, because a conversion to a bigint style integer would cause an unacceptable heap allocation (per his comments), potentially in an interrupt handler. > >> Also, I don't understand his comments about avoiding heap allocations in interrupt handlers. Stack allocating integers is fine, but how do you avoid a heap allocation in a dictionary comprehension or string slice? > > > out of my depth here! The issue is this: hardware occasionally sends an interrupt which must be handled by software. Until it is, the code you wanted to spend time running isn't. (Depending on the interrupt and OS you may also miss other interrupts, but I digress.) This means that interrupt handlers should be very, very fast. By comparison garbage collection is very, very slow. QED, you must avoid the possibility of triggering a garbage collection pass. The way you do this in his scheme is to avoid a (potentially GC-triggering) heap allocation. The problem is that basically everything in a normal python program is heap allocated. Creating an integer or a string allocates space from the heap (think of C's malloc()) to hold that data. When this happens, your malloc implementation essentially rummages around in the heap looking for a close-to-optimally sized spot for the variable to live. At no point will a C program automatically reclaim this space (leading to memory leaks) and so developers must manually call free() to return the space to the heap (leading to use-after-free bugs). The alternative is to allocate on the stack. This is usually used in C like languages for allocation of variables in the local scope- things which are free to be destroyed once we leave that scope. When we do that the variable is basically just added to the end of the stack, and when we leave the local scope we just move the apparent end of the stack back to where it was when we entered that scope. This has the effect of automatically freeing the used memory. Of course, this has a few drawbacks. First, the stack is typically small and fixed size, so it's a bit of a scarce shared resource. On top of that, there's some stack overhead every time you call a function (if you've ever had your code killed because it exceeded the recursion depth limit, this is why). So allocating a lot of data on the stack means less room for calling other functions, including interrupt handlers. Second, it means that a statement of the form global_int = local_int would leave global_int pointing off into space when local_int was collected unless you copy the value somewhere. So, where do you copy the value to? Ah, the heap. But now an innocent assignment between scopes can lead to a heap allocation- which can't be done in an interrupt handler. So now we know that you can't allocate to the heap in an interrupt handler, or assign to an outer scope. I think this rules out comprehensions, but am not sure. What else can't you do? You also probably can't do string operations, since this would take up tons of stack memory. Or bigint operations, since this could lead to an allocation, or... the list goes on. So, I'm skeptical about how python-like this will be. I don't know I would fix that without a lot of hackery. > > -Chris > > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > [email protected]
