----- Original Message -----
From: "Randal L. Schwartz" <
[hidden email]>
>>>>>> "Rob" == Rob Withers <
[hidden email]> 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
Locked
