| Eliot Miranda 2004-05-14, 6:32 pm |
|
Fernando Rodr=EDguez wrote:
> Hi,
>=20
> I've seen this comment on several places, for example the and: method o=
f the
> Boolean class.
>=20
> What does it mean exactly? O:-)
A subset of the control messages (in vw precisely and: ifFalse:=20
ifFalse:ifTrue: ifTrue: ifTrue:ifFalse: or: repeat timesRepeat:=20
to:by:do: to:do: whileFalse whileFalse: whileTrue whileTrue:) get=20
compiled down to bytecodes rather than sends provided that the receiver=20
and arguments conform to certain constraints.
So expr ifTrue: [self doSomething] gets compiled to something like
push expr
popAndJumpOnFalse L1:
push self
send #doSomething
pop
L1:
whereas expr ifTrue: aBlockInAVariable will actually get compiled down=20
to a send of #ifTrue: to expr. So the block arguments to these "macro=20
selectors" don't get created; instead their code is inlined into that of =
the surrounding method.
At the time when the early Smalltalks Smalltalk-76 and Smalltalk-80 were =
implemented this provided an acceptable trade-off between debuggability, =
performance and consistency. It is inconsistent, but arguably more=20
convenient for debugging because one doesn't have to step through the=20
sends of control messages like ifTrue:.
Nowadays some debuggers (e.g. VW's) provide a step that steps within a=20
method and its blocks, eliminating all the annoying stepping through=20
intermediate control code. Also, were Smalltalks to adopt the kind of=20
adaptive optimization technology used by Self and popularised by Java=20
VMs the performance issue could be finessed too. So I expect that=20
within a few years macro selectors will disappear to be replaced by a=20
more consistent optimization scheme, at least that's what a number of us =
hope :)
--=20
_______________,,,^..^,,,____________________________
Eliot Miranda Smalltalk - Scene not herd
|