<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Eliot,</p>
<p> </p>
<blockquote type="cite">Wonderful news!! Why haven;t you committed
anything so we can see your work in progress?? Please, I'd love
to see it.</blockquote>
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.
<p>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.</p>
<p>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.</p>
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).
<p>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.</p>
<p>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.<br>
</p>
<p><br>
</p>
<p> </p>
<blockquote type="cite">You're doing 64-bit, 32-bit or both? What
are the significant PPC platforms these days?</blockquote>
There are basically two disjoint PPC worlds these days, Embedded/IOT
(NXP/Freescale) and Server (IBM).
<p>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").<br>
</p>
<p>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.</p>
<p>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).</p>
<p>- bgs<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 7/6/20 3:27 PM, Eliot Miranda wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAC20JE3SGdNpayGkSebFaP9aoRsoeLScvdh2jpbUQ8SS9CUszg@mail.gmail.com">
<pre class="moz-quote-pre" wrap=""> </pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>Hi Boris,</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Jul 6, 2020 at 8:53
AM Boris Shingarov <<a href="mailto:boris@shingarov.com"
moz-do-not-send="true">boris@shingarov.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> <br>
<br>
On 7/5/20 6:05 PM, Eliot Miranda wrote:<br>
> <br>
> now is the best time ever to attempt a 64-bit or 32-bit
PPC JIT<br>
<br>
..."attempt"?? I have most of it working already. I'll
ping you when I <br>
get it to the same point where we reached with i386 and arm
(i.e. <br>
booting the Reader and being able to evaluate "100
factorial").<br>
</blockquote>
<div><br>
</div>
<div>Wonderful news!! Why haven;t you committed anything so
we can see your work in progress?? Please, I'd love to see
it.</div>
<div> </div>
</div>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">
<div><span style="font-size:small;border-collapse:separate">
<div>_,,,^..^,,,_<br>
</div>
<div>best, Eliot</div>
</span></div>
</div>
</div>
</div>
</blockquote>
</body>
</html>