<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">The original Smalltalk-80 bluebook specification for the language identified the following selectors for special processing.<div class=""><br class=""></div><div class="">ifTrue:, ifFalse:, ifTrue:ifFalse:, ifFalse:ifTrue:, to:do:, to:by:do:, and:, or: ==, timesRepeat:, basicAt:, basicAt:put:, basicSize, basicNew:</div><div class=""><br class=""></div><div class="">This was for performance reasons. A conformant compiler was allowed to inline these selectors after checking the receiver to ensure that it is an appropriate type. The ANSI standard definition of Smalltalk codifies these restricted selectors.</div><div class=""><br class=""></div><div class="">In the 1980’s the Self group at Sun Microsystems (David Ungar et. al.) experimented with no special selectors and a minimal byte code set. They depended instead about type inference and pioneered the idea of the “hot spot” just in time optimizer. IIRC, there was a paper about this work in 1988 or 1989 OOPSLA proceedings.</div><div class=""><br class=""></div><div class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jul 14, 2019, at 6:07 PM, Fernando Gasperi Jabalera via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st" class="">cuis-dev@lists.cuis.st</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi there,<div class=""><br class=""></div><div class="">I'm was trying to understand why code like:</div><div class=""><br class=""></div><div class=""><font face="courier new, monospace" class="">a ifNil: [0] ifNotNil: [1]</font></div><div class=""><br class=""></div><div class="">when parsed got a corresponding <font face="courier new, monospace" class="">MessageNode </font>with an <font face="courier new, monospace" class="">#ifTrue:ifFalse</font> selector and a receiver of the form <font face="courier new, monospace" class="">a == nil</font>. Following the trail lead me to the macro transformations in the <font face="courier new, monospace" class="">MessageNode </font>class. It seems to me that several messages (some loops, boolean operations like <font face="courier new, monospace" class="">and</font> and most of the <font face="courier new, monospace" class="">if</font> messages) are transformed to a special or canonical form, when some conditions on the number of arguments of the blocks for example are satisfied, so that they can be inlined and therefore run faster. Is that correct? Could someone explain a little bit about why it is this way and which cases are chosen to be inlined?</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Fernando.</div><div class=""></div></div>
-- <br class="">Cuis-dev mailing list<br class=""><a href="mailto:Cuis-dev@lists.cuis.st" class="">Cuis-dev@lists.cuis.st</a><br class=""><a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" class="">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br class=""></div></blockquote></div><br class=""></div></div></body></html>