[prev in list] [next in list] [prev in thread] [next in thread]
List: sbcl-devel
Subject: Re: [Sbcl-devel] WASM GC i31ref, usefulness or lack thereof for Lisp
From: Douglas Katzman via Sbcl-devel <sbcl-devel () lists ! sourceforge ! net>
Date: 2020-07-06 15:05:40
Message-ID: CAOrNasyv__aYvwveNG=HvFBUaaCC77j1=Mp=93CTDcwR_-PC_g () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
To make the kind of tight binding of lisp internals to the WASM vm that
you're suggesting (to have GC as a builtin thing etc), you'd have to think
about all the pieces of lisp, not just whether something like lisp's fixnum
type would be directly implementable as 'i31ref'. Personally I can't
even guess about whether 'i31ref' would be useful. It may be, if the users
of such a lisp are willing to have 31-bit integers as their fixnum type.
It would meet the spec, which says that fixnums are at least 16 bits.
Just to point out the range of implementation strategies, the KCL
implementation (https://en.wikipedia.org/wiki/Kyoto_Common_Lisp) defined
most-positive-fixnum as the machine word size (32 bits at the time), had
most fixnums require heap allocation (contrary to the intent of fixnum),
but also defined a small range of fixnums that would always point to a
prebuilt table of the integers from -1024 to 1023 (or something). So to
produce a small fixnum, you could just load the pointer with the proper
index into the table. The net effect was a completely uniform view of any
lisp object as a pointer, without having to decode any bits or even figure
out what address ranges could be reserved on this or that architecture for
funny encodings.
If there aren't any SBCL-specific issues at hand, I don't know how else to
help you.
On Thu, Jul 2, 2020 at 10:04 AM Sabine Schmaltz <sabine@tarides.com> wrote:
> Hello,
>
> sorry, I haven't been very precise:
>
> There are recurring discussions on the usefulness or importance of
> `i31ref` on the WebAssembly community group. Some parties are very
> reluctant with respect to committing to making `i31ref` a part of the
> spec. Some are looking for better solutions that solve the same problem
> (efficiently storing integers on the heap).
>
> My goal is to find out if Lisp, not necessarily SBCL, can make use of
> the `i31ref` spec of WebAssembly, if that Lisp were to be implemented on
> WebAssembly and use WebAssembly's built-in GC.
>
> That the likely route to WASM for SBCL is through LLVM is definitely an
> interesting point. I take it that means that SBCL would definitely bring
> its own GC to WASM?
>
> For Ocaml, we would very much appreciate a 63-bit efficient integer type
> on the WASM GC, as the 31-bit integer type only gives us a
> reasonably-efficient 32-bit target on WASM. Efficient 63-bit integers,
> however, are extremely unlikely to make it into the specification, as at
> least some of the browser engine vendors cannot efficiently implement
> that, due to choices in their existing codebase. 31-bit efficient
> integers, however, the existing browser engines can support with
> reasonable effort.
>
> Lisp as a language is on the Tiobe index. In some people's ears that
> makes Lisp's words more important than OCaml's. :)
>
>
> Best,
> Sabine
>
>
> On 7/2/20 3:06 PM, Douglas Katzman wrote:
> > Hi, It's not clear what goal you're trying to achieve. Your email didn't
> > say anything like "I would like for SBCL to compile to WASM" or "I would
> > like /some/ lisp implementation which compiles to WASM".
> > i.e. Are you asking about SBCL or are you asking about whether WASM
> > could host a Lisp environment, potentially forked from SBCL?
> >
> > As to answering the question "Could SBCL gain something
> > (portability/speed) if it just compiled to WASM?" I would say that at
> > first glance this is not an interesting angle to the SBCL project.
> > But note that I'm not saying it wouldn't improve the portability; I'm
> > saying that wasm is not likely the route that SBCL would take to achieve
> > it- LLVM is.
> >
> > That's on the one hand. On the other, if your position is "We
> > desperately wish to retarget SBCL to compile to WASM as its VM", then
> > I'd say, sure, that's possible in theory, and, sure, you might be able
> > to leverage the builtin GC capability. The 31-bit integer format as an
> > efficient integer type (not requiring heap allocation) would be a
> > regression on the 64-bit platforms; SBCL's efficient integer type has
> > anywhere between 60 to 63 significant bits depending on the CPU.
> >
> > In terms of whom you could discuss this with, unless some user raises
> > his/her hand saying "I want that!", the mailing list is really the best
> > channel for discussion.
> >
> > Doug
> >
> > On Thu, Jul 2, 2020 at 5:07 AM Sabine Schmaltz <sabine@tarides.com
> > <mailto:sabine@tarides.com>> wrote:
> >
> > Hello everyone,
> >
> >
> > For context: I'm working on compiling OCaml to WebAssembly, and I am
> > involved in the discussions of the WebAssembly community group. I
> know
> > only the basics of Lisp.
> >
> > I've been looking at the WebAssembly garbage collector extension
> > specification.
> >
> > The WASM GC specification tentatively has a type `i31ref`, which is a
> > 31-bit integer embedded into a pointer:
> >
> https://github.com/WebAssemably/gc/blob/b2da61b6c444459a60e32a2e021f2631575b1795/proposals/gc/MVP.md#unboxed-scalars
>
> >
> > I wonder,
> >
> > 1. would `i31ref` be of any use at all to Lisp, if Lisp were to
> compile
> > to WASM in a way that uses WASM's GC?
> >
> > 2. what would a built-in GC of WASM need to look like in order to be
> > useful as a compilation target, to Lisp? Is there such a thing that
> can
> > be realistically reconciled with a general-purpose GC such as WASM
> can
> > provide?
> >
> > 3. are there any efforts or interest to compile to WASM in a way that
> > uses a built-in GC? Or is the consensus here that the better
> > solution is
> > to compile to linear memory and bring your own GC, because Lisp's
> > memory
> > model is just too different from the mainstream?
> >
> > 4. is there someone specific I can contact to discuss this?
> >
> >
> > Best,
> > Sabine Schmaltz
> > --
> > Sofware Engineer @ Tarides
> >
> >
> > _______________________________________________
> > Sbcl-devel mailing list
> > Sbcl-devel@lists.sourceforge.net
> > <mailto:Sbcl-devel@lists.sourceforge.net>
> > https://lists.sourceforge.net/lists/listinfo/sbcl-devel
> >
>
[Attachment #5 (text/html)]
<div dir="ltr"><div>To make the kind of tight binding of lisp internals to the WASM \
vm that you're suggesting (to have GC as a builtin thing etc), you'd have to \
think about all the pieces of lisp, not just whether something like lisp's fixnum \
type would be directly implementable as 'i31ref'. Personally I can't \
even guess about whether 'i31ref' would be useful. It may be, if the users of \
such a lisp are willing to have 31-bit integers as their fixnum type. It would \
meet the spec, which says that fixnums are at least 16 \
bits.</div><div><br></div><div>Just to point out the range of implementation \
strategies, the KCL implementation (<a \
href="https://en.wikipedia.org/wiki/Kyoto_Common_Lisp">https://en.wikipedia.org/wiki/Kyoto_Common_Lisp</a>) \
defined most-positive-fixnum as the machine word size (32 bits at the time), had most \
fixnums require heap allocation (contrary to the intent of fixnum), but also defined \
a small range of fixnums that would always point to a prebuilt table of the integers \
from -1024 to 1023 (or something). So to produce a small fixnum, you could just \
load the pointer with the proper index into the table. The net effect was a \
completely uniform view of any lisp object as a pointer, without having to decode any \
bits or even figure out what address ranges could be reserved on this or that \
architecture for funny encodings.</div><div><br></div><div>If there aren't any \
SBCL-specific issues at hand, I don't know how else to help \
you.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On \
Thu, Jul 2, 2020 at 10:04 AM Sabine Schmaltz <<a \
href="mailto:sabine@tarides.com">sabine@tarides.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br> <br>
sorry, I haven't been very precise:<br>
<br>
There are recurring discussions on the usefulness or importance of <br>
`i31ref` on the WebAssembly community group. Some parties are very <br>
reluctant with respect to committing to making `i31ref` a part of the <br>
spec. Some are looking for better solutions that solve the same problem <br>
(efficiently storing integers on the heap).<br>
<br>
My goal is to find out if Lisp, not necessarily SBCL, can make use of <br>
the `i31ref` spec of WebAssembly, if that Lisp were to be implemented on <br>
WebAssembly and use WebAssembly's built-in GC.<br>
<br>
That the likely route to WASM for SBCL is through LLVM is definitely an <br>
interesting point. I take it that means that SBCL would definitely bring <br>
its own GC to WASM?<br>
<br>
For Ocaml, we would very much appreciate a 63-bit efficient integer type <br>
on the WASM GC, as the 31-bit integer type only gives us a <br>
reasonably-efficient 32-bit target on WASM. Efficient 63-bit integers, <br>
however, are extremely unlikely to make it into the specification, as at <br>
least some of the browser engine vendors cannot efficiently implement <br>
that, due to choices in their existing codebase. 31-bit efficient <br>
integers, however, the existing browser engines can support with <br>
reasonable effort.<br>
<br>
Lisp as a language is on the Tiobe index. In some people's ears that <br>
makes Lisp's words more important than OCaml's. :)<br>
<br>
<br>
Best,<br>
Sabine<br>
<br>
<br>
On 7/2/20 3:06 PM, Douglas Katzman wrote:<br>
> Hi, It's not clear what goal you're trying to achieve. Your email \
didn't <br> > say anything like "I would like for SBCL to compile to \
WASM" or "I would <br> > like /some/ lisp implementation which compiles \
to WASM".<br> > i.e. Are you asking about SBCL or are you asking about \
whether WASM <br> > could host a Lisp environment, potentially forked from \
SBCL?<br> > <br>
> As to answering the question "Could SBCL gain something <br>
> (portability/speed) if it just compiled to WASM?" I would say that at <br>
> first glance this is not an interesting angle to the SBCL project.<br>
> But note that I'm not saying it wouldn't improve the portability; \
I'm <br> > saying that wasm is not likely the route that SBCL would take to \
achieve <br> > it- LLVM is.<br>
> <br>
> That's on the one hand. On the other, if your position is "We <br>
> desperately wish to retarget SBCL to compile to WASM as its VM", then <br>
> I'd say, sure, that's possible in theory, and, sure, you might be able \
<br> > to leverage the builtin GC capability. The 31-bit integer format as an <br>
> efficient integer type (not requiring heap allocation) would be a <br>
> regression on the 64-bit platforms; SBCL's efficient integer type has <br>
> anywhere between 60 to 63 significant bits depending on the CPU.<br>
> <br>
> In terms of whom you could discuss this with, unless some user raises <br>
> his/her hand saying "I want that!", the mailing list is really the \
best <br> > channel for discussion.<br>
> <br>
> Doug<br>
> <br>
> On Thu, Jul 2, 2020 at 5:07 AM Sabine Schmaltz <<a \
href="mailto:sabine@tarides.com" target="_blank">sabine@tarides.com</a> <br> > \
<mailto:<a href="mailto:sabine@tarides.com" \
target="_blank">sabine@tarides.com</a>>> wrote:<br> > <br>
> Hello everyone,<br>
> <br>
> <br>
> For context: I'm working on compiling OCaml to WebAssembly, and I \
am<br> > involved in the discussions of the WebAssembly community group. I \
know<br> > only the basics of Lisp.<br>
> <br>
> I've been looking at the WebAssembly garbage collector extension<br>
> specification.<br>
> <br>
> The WASM GC specification tentatively has a type `i31ref`, which is a<br>
> 31-bit integer embedded into a pointer:<br>
> <a href="https://github.com/WebAssemably/gc/blob/b2da61b6c444459a60e32a2e021f2631575b1795/proposals/gc/MVP.md#unboxed-scalars" \
rel="noreferrer" target="_blank">https://github.com/WebAssemably/gc/blob/b2da61b6c444459a60e32a2e021f2631575b1795/proposals/gc/MVP.md#unboxed-scalars</a><br>
> <br>
> I wonder,<br>
> <br>
> 1. would `i31ref` be of any use at all to Lisp, if Lisp were to \
compile<br> > to WASM in a way that uses WASM's GC?<br>
> <br>
> 2. what would a built-in GC of WASM need to look like in order to be<br>
> useful as a compilation target, to Lisp? Is there such a thing that \
can<br> > be realistically reconciled with a general-purpose GC such as \
WASM can<br> > provide?<br>
> <br>
> 3. are there any efforts or interest to compile to WASM in a way that<br>
> uses a built-in GC? Or is the consensus here that the better<br>
> solution is<br>
> to compile to linear memory and bring your own GC, because Lisp's<br>
> memory<br>
> model is just too different from the mainstream?<br>
> <br>
> 4. is there someone specific I can contact to discuss this?<br>
> <br>
> <br>
> Best,<br>
> Sabine Schmaltz<br>
> --<br>
> Sofware Engineer @ Tarides<br>
> <br>
> <br>
> _______________________________________________<br>
> Sbcl-devel mailing list<br>
> <a href="mailto:Sbcl-devel@lists.sourceforge.net" \
target="_blank">Sbcl-devel@lists.sourceforge.net</a><br> > <mailto:<a \
href="mailto:Sbcl-devel@lists.sourceforge.net" \
target="_blank">Sbcl-devel@lists.sourceforge.net</a>><br> > <a \
href="https://lists.sourceforge.net/lists/listinfo/sbcl-devel" rel="noreferrer" \
target="_blank">https://lists.sourceforge.net/lists/listinfo/sbcl-devel</a><br> > \
<br> </blockquote></div>
_______________________________________________
Sbcl-devel mailing list
Sbcl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic