[Vm-dev] Probably pointless endianness question re: Float changes circa 4.6

Boris Shingarov boris at shingarov.com
Tue Jul 21 15:54:16 UTC 2020

Hi Eliot,

> Wonderful news!!  Why haven;t you committed anything so we can see 
> your work in progress??  Please, I'd love to see it.
There isn't really anything that's not public.  (Well ok, there are some 
exceptions -- some early-prototype experiments re: deriving Smalltalk 
from Sail, stuff that's definitely too rough yet to be useful to anyone 
but myself).  The problem is not publishing, the problem is 
integration.  We have all the pieces working but some only work in 
Squeak, some in Pharo, some in Smalltalk/X.  Multiply that by the 
dimension that some are applied to OpenSmalltalk VM and some to Bee 
DMR.  Sure I could bring a piece from (say) Smalltalk/X into Squeak and 
commit it on the squeaksource repo, but what's the point, other than to 
create confusion and frustration for others? At least the stuff I 
committed here (VMMaker-over-ULD instead of Alien) actually works IN 
SQUEAK: so if someone is curious to try it, they can start from where 
it's reasonable to expect that they will be able to understand what the 
code does.  (And yes, I am always here available to answer questions).  
If they are curious to see how I infer an assembler and disassembler 
from PDL, they can head over to the Pharo-ArchC repo and start from 
watching that code run in their Pharo image (because it's been working 
well for the past 5 years).  But to expect that someone will load this 
unfamiliar bunch of code into Squeak and struggle to make it work, I 
think this would be a totally unreasonable, simply idiotic, expectation.

There are reasons why we ended up in this state of fragmentation.  One 
is that I am interested in things like proving correctness of 
self-modifying code, or like auto-inferring a RISC-V toolchain from its 
Sail2 spec, much more than in Squeak or Pharo per se.  So if I know it's 
going to take me a week to build a proof-of-concept of something in 
Pharo vs a year in Smalltalk/X, I'll do that piece in Pharo no matter my 
preferences. Unfortunately, there are many of these situations forcing 
me to work in non-preferred dialects.

At this point in time, though, we need to sit down and brainstorm how to 
change this, because the components have now matured enough to reach 
diminishing returns from working on them separately.

I'd like to somehow integrate to at least allow for short-term progress 
(now we can't even exchange code easily -- Tonel and whatnot).

By short-term, I mean, probably, start from plugging the target-agnostic 
assemblers: things like e.g. CogARMCompiler>>faddd:with:, this kind of 
hand-written source just doesn't belong in the source-codebase: this 
knowledge is trivially inferred from the machine-readable CPU spec.  
(And yes, I know how to slang the inferred form, although I have not 
actually done it yet).  This should simplify the CogCompilers by an 
order of magnitude.

The second thing I want to do sooner than later is erase the 
black-and-white division between simulation and production: for example 
in Cogit>>compileCallFor:..., either ALL of them go the cCode: [aRoutine 
asUnsignedInteger] way, or ALL of them go the inSmalltalk: [self 
simulatedTrampolineFor: aRoutine] way.  John Sarkela already taught us 
how to do it granularly, i.e. one simulation run can have some runtime 
calls executed as native CPU code, and some others be simulated via 
fakeAddress.  That's not even hard, but what stands in the way is that 
we have two different address space layouts.  Obviously these will need 
to become unified.

> You're doing 64-bit, 32-bit or both?  What are the significant PPC 
> platforms these days?
There are basically two disjoint PPC worlds these days, Embedded/IOT 
(NXP/Freescale) and Server (IBM).

Right now, only PPC32 is actively moving forward.  I am testing in gem5 
simulation, as well as on two different dev boards from Freescale (with 
e300 and e500) and on the 440 block within XC5VFX (those are 
past-end-of-life by Xilinx, but are *excellent* debug targets (esp. when 
semihosting like in OpenSmalltalkVM) and very inexpensive because they 
are "old tech").

PPC64 is kind of in a weird state.  In gem5 there are out-of-tree 
patches for PPC64 support, I've tried those and found it frustrating to, 
when something doesn't work, never be sure if it's their bug or mine.

On the hardware side, there are some open-source implementations, one of 
them from IBM, but it's not quite there yet: every time I configure an 
FPGA with it and try running my JIT, I bump into one issue or another.  
I try to participate in resolving them, but at this stage it's not a 
very productive tool for JIT testing.  (It's an immensely fun mode to 
run a Smalltalk VM in, though: no-OS, with MMU switched off, so there is 
nothing to detect a fake address, these are MMIO to a purpose-built 
register pulling an interrupt line on access... fun toy but I hope it 
will mature soon).

- bgs

On 7/6/20 3:27 PM, Eliot Miranda wrote:
> Hi Boris,
> On Mon, Jul 6, 2020 at 8:53 AM Boris Shingarov <boris at shingarov.com 
> <mailto:boris at shingarov.com>> wrote:
>     On 7/5/20 6:05 PM, Eliot Miranda wrote:
>     >
>     > now is the best time ever to attempt a 64-bit or 32-bit PPC JIT
>     ..."attempt"??  I have most of it working already.  I'll ping you
>     when I
>     get it to the same point where we reached with i386 and arm (i.e.
>     booting the Reader and being able to evaluate "100 factorial").
> Wonderful news!!  Why haven;t you committed anything so we can see 
> your work in progress??  Please, I'd love to see it.
> _,,,^..^,,,_
> best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200721/ecbfa2c7/attachment-0001.html>

More information about the Vm-dev mailing list