Hi Jecel,

El lun., 21 ene. 2019 a las 22:27, Jecel Assumpcao Jr. (<jecel at merlintec.com>)
escribió:

> Hernán Morales Durand wrote on Mon, 21 Jan 2019 18:13:45 -0300
> > I have some possible myths, but I'd like to confirm or reject:
> >
> > - All Smalltalk bytecode sets are stack-based VM. (?)
> > - Bytecodes are always fixed-size. (?)
>
> SOAR (Smalltalk On A RISC, now renamed as RISC-III) used a 32 bit
> register based instruction set and Smalltalk sources were translated to
> that. They did regret dumping bytecodes later in their project as some
> things became more complicated and the increase in memory use was very
> expensive at that time.
>
> https://apps.dtic.mil/dtic/tr/fulltext/u2/a172800.pdf
>
> SOM (Simple Object Machine) is a set of Smalltalk VMs where some of them
> represent code as abstract syntax trees instead of bytecodes.
>
> http://som-st.github.io/
> http://www.hpi.uni-potsdam.de/hirschfeld/projects/som/
>
> > - Most of the time spent by a VM is in the instruction interpreter.
> (actually it's in the GC right?)
>
> That will vary from one VM to another. On page 179 of the "green book"
> you can see a nice graph of the space and time used by different part of
> the Apple Smalltalk (from which Squeak evolved) and on page 177 you can
> find the numbers used to create the chart.
>
> http://sdmeta.gforge.inria.fr/FreeBooks/BitsOfHistory/
>
> 10.2% of the time in the fetch loop, 16.0% in the bytecode interpreter,
> 39.2% in sends and returns, 22.6% in the memory management and 10% in
> primitives.
>
> Adding the first 3 numbers you get 10.2+16.0+39.2 = 65.4% in the
> instruction interprter while the GC is part of the 22.6% which is the
> memory management. That said, in Squeak gcc tricks really helped with
> the fetch loop and the stack VM greatly reduced the send/return
> overhead. So it might be the case that the GC dominates performance. Or
> not - we have to measure and see.
>
> > - You cannot serialize objects containing blocks. (IIRC one can use
> MessageSends)
>
> Given that the image contains blocks, that can't be true. Obviously
> serializing a subset of objects is a harder problem than just dumping
> memory, but I consider images a proof of existence.
>
> > - Image cannot be bootstrapped. (This is possible in ST/X and now in
> Pharo I think).
>
> Little Smalltalk is a good example of taking a textual representation
> and bootstrapping an image from it.


Yes, sadly some of the LS implementations were lost in time and need to be
tracked now, http://www.littlesmalltalk.org is now chinese thing, PDST and
Parla were based in LittleSmalltalk 3 but only accessible through archive:
http://web.archive.org/web/20051025043437/http://www.copyleft.de/Parla/Parla.html.
There is another implementation now : https://github.com/0x7CFE/llst
however didn't checked yet.

>
> GNU Smalltalk didn't even use images
> the last time I looked at it. I consider Self to be a Smalltalk (just
> not a Smalltalk-80) and it can start with either a snapshot (its name
> for image) or with an empty world and load text files (possible because
> the source to bytecode compiler is included in the VM).
>
>
I always wondered about how much performance is gained moving the all the
Compiler infrastructure into the VM.

> - All Smalltalks includes UI classes. (GemStone doesn't have AFAIK)
>
> The MS-DOS port of Squeak had no GUI, just a command line prompt. That
> was also the case for GNU Smalltalk and Little Smalltalk.
>
>
Didn't knew there was a DOS-only based Squeak. Any link out there to try?

For GST I should note there is an interesting project using GTK which
provides a gst-browser, although cannot say if now is part of GNU Smalltalk.


> > .- All implementations uses direct pointers, (GST?)
>
> The RoarVM for Squeak uses object tables. In fact, the lack of direct
> pointers in early implementations is what led to the use of #become:
> which complicated the adoption of direct pointers. VisualWorks has an
> indirection pointer in the header - see slide 7 of
>
> https://www.slideshare.net/esug/spur-a-new-object-representation-for-cog
>
>
Thank you for the pointer, really informative presentation.


> > - All implementations uses green threads. (VAST? MT?)
>
> I would say this was a side effect of patching the original Smalltalk,
> which was its own operating system (and so the idea of green thread
> doesn't apply) to run on top of Unix on commercial workstations. All the
> old code supposed the mix of cooperative and preemptive multithreading
> that breaks down if you have multiple native threads.
>
> Some from scratch Smalltalks copied this model while others (I am pretty
> sure it was the case for MT, as you mentioned) had their libraries
> written with native threads in mind.
>
> -- Jecel
>
>
Thank you, added with credits to
https://github.com/hernanmd/falsehoods_smalltalk

Cheers,

Hernán
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190122/fb7faeb6/attachment.html>