Re: Advice on ST-Object data-structure setup

[Basile Starynkevitch]

On 4/16/24 23:14, ken.dickey@whidbey.com wrote:
> Greetings,
>
> I am looking at porting a toy Smalltalk-in-Scheme implementation to 
> Guile.
>
> [Note https://github.com/KenDickey/Crosstalk ].

On github I (Basile Starynkevitch) am https://github.com/bstarynk and 
contributing to https://github.com/RefPerSys (see also 
http://refpersys.org/ ...)

> The idea is for simplicity first, then making into a module and 
> potentially evolving Smalltalk into a supported, compiled ",language" 
> in the Guile way.
>
> The first bit of business is to get the mechanics working.  For this I 
> need to have an St-Object which is basically a Vector but which 
> answers #false to vector? and #true to st-object?
>
> [Note https://github.com/KenDickey/Crosstalk/blob/master/st-kernel.scm ]
>
> I note that one might change the T7 type-tag from 0x0d (vector) to 
> 0x6d (currently unused) with a quick bitwise-or, but would like some 
> advice on the best way to do this or some alternate.  I would prefer 
> to work in Scheme, not C, BTW.


I think it depends upon your goals; I assume your x86-64 computer is 
running some Linux OS. :

Do you want to code in Smalltalk as quickly as possible? Then install 
GNU smalltalk. https://www.gnu.org/software/smalltalk/ (it is free 
software, a bit old, but you can study the source code).

Do you care about efficiency? Then you want to generate code. A 
possibility is to generate C or C++ code at runtime (in some temporary 
file) then to compile that file into a temporary plugin (forking some 
gcc command) and dlopen that plugin. This in practice can be done many 
dozen of thousands of time in the same process (see 
https://github.com/bstarynk/misc-basile/blob/master/manydl.c for an 
example). See also https://arxiv.org/abs/1109.0779 and some old 
(unmaintained) open source code on 
http://starynkevitch.net/Basile/gcc-melt/ that you'll need to adapt.

If you want to generate efficient machine code directly and accept to 
use a C++ library for that, consider using https://asmjit.com/ (this 
requires knowledge of the x86-64 instruction set).

If you want to generate quickly and portably some (less efficient) 
machine code, use GNU lightning 
<https://www.gnu.org/software/lightning/>. This library generates 
machine code, but in a more abstract and portable (and less efficient) 
way than asmjit.

If you want to take advantage of most optimization passes of a recent 
GCC <https://gcc.gnu.org/> compiler (ie GCC 13 at least) link to its 
libgccjit <https://gcc.gnu.org/onlinedocs/jit/> library (which is the 
GCC compiler packaged as a library). Code generation is as slow as GCC 
can be, but the generation can be optimized by GCC so the generated code 
can be really efficient.

My pet open source project is the RefPerSys ("Reflexive Persistent 
System") inference engine (in C++, GPLv3+ licensed) on 
https://github.com/RefPerSys/RefPerSys/ while it is not Smalltalk, it 
shares a lot of features with it (so I think you could borrow a lot of 
code from it):

RefPerSys has immutable values and mutable objects (I call RefPerSys 
value something which is either an immutable value or a mutable object, 
or null; it fits in a 64 bits word). It is capable of dumping the entire 
heap in JSON textual files - see 
https://github.com/RefPerSys/RefPerSys/tree/master/persistore (and also 
in C++ code), and is loading the entire heap at startup (from a set of 
textual files). It has a precise (multi-threaded) garbage collector and 
generate code at runtime.

Immutable values can be scalars (integers, boxed doubles, strings, ....) 
or composite (finite set of objects, finite tuple of objects, ....). the 
null pointer is interpreted as a lack of value.

RefPerSys objects are mutable, each containing a C++ mutex to serialize 
access or modification of the object. The object model is Smalltalk like 
(or ObjVLisp like): each object has a class (which is an object itself). 
Most objects are persistent (so dumped and reloaded) but some are 
temporary (dumped as null). Each object contains a mutable sequence of 
components (RefPerSys values) and a mutable finite dictionary of 
attribute pairs. An attribute pair has a key (which is a RefPerSys 
object) with a non-null RefPerSys value associated to it.  (This is like 
in Smalltalk). In addition to components and attributes, a RefPerSys 
object may carry a payload (some C++ class) for extra data.

RefPerSys is work in progress (we are seeking some ITEA consortium 
interested by it, or even informal contributors). See also 
http://refpersys.org/ecai2020-highlight-refpersys.pdf and 
http://starynkevitch.net/Basile/refpersys-design.pdf

RefPerSys is currently lacking a syntax (this is being discussed right 
now,mid April 2024, on 
https://framalistes.org/sympa/info/refpersys-forum ), but you could add 
to it some Smalltalk parsing code (e.g. from GNU smalltalk). For that, 
improve its parsrepl_rps.cc C++ file.

Hoping this could be useful to some of you.

Thanks for reading.

Regards from near Paris in France.

--
Basile Starynkevitch<basile@starynkevitch.net>
(only mine opinions / les opinions sont miennes uniquement)
8 rue de la Faïencerie, 92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/
See/voir:https://github.com/RefPerSys/RefPerSys