guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Advice on ST-Object data-structure setup


From: Basile Starynkevitch
Subject: Advice on ST-Object data-structure setup
Date: Wed, 17 Apr 2024 09:14:42 +0200
User-agent: Mozilla Thunderbird

(sorry, resending as plain text to guile-user)


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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]