[Vm-dev] reorganizing opensmalltalk-vm

Eliot Miranda eliot.miranda at gmail.com
Sun Oct 28 19:33:39 UTC 2018

Hi Ben,

On Thu, Oct 25, 2018 at 8:54 PM Ben Coman <btc at openinworld.com> wrote:

> Just a few thoughts. Take with a grain of salt.
> On Fri, 26 Oct 2018 at 01:31, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
>> Hi All,
>>     efforts are underway to include the VMMaker source in the
>> opensmalltalk-vm repository.
> Very nice.
>> I'm hoping to see all the Smalltalk source included in the Tonel format
>> (one file per class, and one file per extended class), with support for
>> Pharo and Squeak quite soon.  This is therefore an opportunity to also
>> reorganize the structure of the repository to have a more comprehensible
>> and less cluttered top-level directory.  I'm interested in people's ideas.
>>  here are two suggestions.
>> 1. move all source under src and all builds under build. So
>>     src/smalltalk/                  all the VMMaker-related packages
>>                         AioPlugin
>>                         BytecodeSets
>>                         Cog
>>                         VMMaker
> Could you explain what would be in VMMaker?
> I thought all the plugins were a part of VMMaker rather than siblings.
> i.e. why not src/vmmaker/AioPlugin & src/vmmaker/vm (or src/vmmaker/Core)
> Also what would be in Cog?  just the JIT stuff?

The above structure is merely a mirror of the existing package structure.
See e.g. image/BuildSqueakSpurTrunkVMMakerImage.st

>>     src/generated/              all the generated code
>>                         plugins/     all generated plugins
>>                         v3              the V3 VM (now src/vm)
>                         spur32       the 32-bit Spur VM (now spursrc/vm)
>>                         spur64       the 64-bit Spur VM (now spur64src/vm)
> Those renames definitely add clarity and will help newcomers, particularly
> the v3 one.
> However I think "src" should just be for "raw" sources.
> A top level "generated" folder per your point[2.] would be good, but
> perhaps also sllmming the name down to "gensrc".


    src/platforms                 the current platforms directory
>>     src/third-party/
>                         processors
> Can "src" be kept just for "our" sources ?
> IIUC, processors/IA32 contains third-party source folder "bochs"
> as well our our code which looks like build script in folders
> "$(PLATFORM)bochs"
> Ideally that part should be split out under the build folder, and the
> perhaps the third-party source goes under root folder "othersrc"
> but the existing "processors" folder as a whole is not getting in the way,
> so for now leave it.
> Though the term "processors" has broad meaning and it may make more sense
> to newcomers if the folder was "processor-sim" or "cpu-sim".


>     build/                             the current build directories
>>         macos32x86
>>         macos64x64
>>     deploy/
>>     image/
> Maybe an idea for the future, "image" could be much more than just holding
> scripts to create the build.image.
> Initially it could hold image-side code for CI testing of the VM.
> But also it seed the growth of a common image-side codebase for the low
> level stuff between distributions.
> Pharo's plan is to modularize things to build their shipping image from
> multiple repositories,
> so it shouldn't matter to them if their bootstrap pulls some parts direct
> from opensmalltalk.
> Or maybe it would be better to have all that in a different repo
> https://github.com/OpenSmalltalk/opensmalltalk-image
> In any case, "image" as things currently stand feels a bit odd at the
> top-level.
> It seems it would fit better under "scripts/image", or "scripts/dev.image"
> btw, what is spec/locode.xml ?
> Is that something loaded by the image-side by a user?
> That might fit under image/specs/lowcode.xml ?

Ronie knows, but my limited understanding is that spec/locode.xml specifies
the semantics of the locoed instruction set, such that versions in a
specific language, assembler or machine code can be autogenerated.  So the
Smalltalk implementation of the locoed instructions in Sista are
autogenerated from spec/locode.xml.

>> 2. single top-level directories for generated source, and Smalltalk
>> source, everything else unchanged
>> smalltalksrc/             all the VMMaker-related packages
>> generatedsrc/           all the generated code as above in src/generated,
>> but in generatedsrc instead
> platforms
>> processors
>> third-party
>> tests
>> deploy
>> Obviously #1 is more work but produces a much cleaner structure.  Other
>> suggestions? Reactions to the above?
>> _,,,^..^,,,_
>> best, Eliot
> 3. So top level could look like...
>    src/                  our own root sources, native and smalltalk
> VMMaker
>    gensrc/            generated from VMMaker
>    othersrc/          third-party libs kept intree (manually or via
> subtree or submodule)
>    cachesrc/        sources downloaded during build (empty folder on
> github except readme.md)
>    scripts/
>    build/
>    deploy/
> with second level...
>    src/smalltalk/                 all the VMMaker-related packages
>    src/platforms                 the current platforms directory
>    src/third-party/              only the spec files

I'm leaning towards

with a good README ;-)

> The main readme says "Another distinction is between Stack, Cog and Sista
> VMs",
> so would it be better to be explicit about which ones are Cog?
> Also would it be better to be explicit about v3 only being 32 bit (if I
> guess correctly)
>    gensrc/plugins
>    gensrc/v3cog32                   old src
>    gensrc/v3stack32                old stacksrc
>    gensrc/spurstack32            old spurstacksrc
>    gensrc/spurstack64            old spurstack64src
>    gensrc/spurcog32               old spursrc
>    gensrc/spurcog64               old spur64src
>    gensrc/spursista32            old spursista64src
>    gensrc/spursista64            old spursista64src
>    gensrc/spurlowcode32      old spurlowcodesrc
>    gensrc/spurlowcode64      old spurlowcode64src
>    othersrc/gdb
>    othersrc/bochs         an alternative is to mirror/fork bochs into
> opensmalltalk-vm/bochs and have a build script pull that to your machine
>                                         e.g.
> https://github.com/search?q=bochs+mirror&type=Repositories
>                                        you can have one branch called
> "mirror" that only *ever* sucks from upstream
>                                        with any custom mods in a branch
> called "Cog".
>    scripts/ci
>    scripts/image
>    scripts/git
>    build/linuxXXX
>    build/winXXX
>    deploy/squeak
>    deploy/pharo
>    deploy/newspeak
> cheers -ben

best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20181028/772833b4/attachment.html>

More information about the Vm-dev mailing list