Fw: self error: 'A block compiles more than 1K bytes of code'

Rob Withers reefedjib at yahoo.com
Sun Oct 21 04:42:59 UTC 2007


 ----- Original Message ----- 
 From: "Randal L. Schwartz" <merlyn at stonehenge.com>


>>>>>> "Rob" == Rob Withers <reefedjib at yahoo.com> writes:
>
> Rob> In ParseNode>>#emitLong:code:on:, this error is being signalled for 
> me
> Rob> and my new transform code.  I think this is emitting a long jump.  Is
> Rob> 1024 the limit a long jump can make and so this represents a hard 
> error?
> Rob> Would it be possible to code a bytecode (say 127) to use 2 extra 
> bytes
> Rob> for an extraLongJump instruction to get around this?
>
> Is it possible that the warning is there for a good reason, as in perhaps 
> you
> should be refactoring the method so that it doesn't have so much source 
> code?

 :-)

 The issue is I rewrote the macro transformation of certain messages, like
 #ifTrue: and #whileFalse:.  The way I rewrote them increased the size of 
the
 resulting bytecodes, considerably in the case of large blocks of code and
 even more with nested messages that also get macro transformed.

 I basically wrote a macro that would test if the receiver was a Boolean, in
 the case of #ifTrue:, or that the receiver was a block in the case of
 #whileFalse:.  The ifTrue branch of the test holds the original optimized
 macro expansion, while the ifFalse branch of the test holds the bytecodes 
to
 do a real message send.  Now the unfortunate part: each branch needs it own
 block bytecodes, so it duplicates the block creation.   I wish I could do 
it
 with one block creation shared between the two uses of it (macro and 
normal)
 but I don't see it.  I'd love to learn otherwise.

 Finally, this is so that all existing methods in the image would get
 recompiled.  So there already exist methods that are ok in size now, but
 exceed this size limit when my macro transformations are applied.  The
 method I recompiled to discover this error is Parser>>#messagePart:repeat:.


> The more I edit long methods, the more I realize how cool short methods
> are. :)

 I totally agree with you here.  I like no more than 4 lines, personally.

Cheers,
Rob




More information about the Squeak-dev mailing list