Re: [MIT-Scheme-devel] Bug: Poor error message; maybe a sign of something worse?

[Matt Birkholz]

> From: Taylor R Campbell <address@hidden>
> Date: Tue, 20 Sep 2011 19:10:19 +0000
> 
> [...]
> To recap:  Alexey's symptom is that LIAR chokes when it generates a
> straight-line sequence of machine code that exceeds 64 kilobytes.  The
> immediate source of the problem is that the format word just before
> any straight-line sequence of code saying how far it is from the start
> of the previous one is a 16-bit field.

Break the block.  What's a little register dumping and interrupt
testing for a healthy, young machine? [pinch]

> I could `fix' it by taking, say, the maximum value and reinterpreting
> it to mean an extra-long 32-bit format word precedes it or something.

Please don't.

> However, that doesn't solve the real problem, which is that straight-
> line sequences of code are uninterruptible, either by ^G or by a heap
> overflow or whatever.

Thus the "basic" in "basic block".  I'm afraid your "problem" is my
"simple".

> We allow interrupt handlers [only when] the stack looks good.
> 
> As long as the code polls for interrupts periodically, this is OK.
> Currently, `periodically' is at most every 64 kilobytes of machine
> instructions, which is reasonable enough, but expanding that to every
> four gigabytes of instructions sounds rather sketchy.

Ya: "No" to 4GB basic blocks.

> Another approach would [...] take substantial re-engineering [...]

And a BIG smack up side the portabimini.

> I don't see any nice way to work around or solve this problem, without
> just splitting the input to LIAR into separate procedures, which is
> what I have advised Alexey to do.

Hang on; you lost me.  What basic block spans procedures?  How does
separating procedures break basic blocks?

> [*] As an aside, I don't think we test for heap overflow reliably: I
> suspect the heap can overflow before we poll for interrupts.
> Certainly there are no formally engineered limits in place, or
> bookkeeping in the code generator, to prevent that from happening.
> But that's a separate issue.

There is a 64KB basic block limit.  It's not easy to prove, from that
limit, that some number of bytes in a safe-landing cushion will always
be SAFE, but I want to run some things in the GC interrupt handler
anyway.  That cushion just better be BIG. ;-)