[erlang-questions] Fwd: Is there a good source for documentation on BEAM?

[Jonathan Coveney]

I think that any time you find yourself justifying not documenting things,
it's probably a mistake :) I know it'd be a lot of someone's time (I read
the pdf in dropbox and found it very helpful, and think that a document
like that that covered more of the opcodes in the context of more
complicated functions would be extremely helpful). I agree that the
External BEAM is probably the thing to focus on.

I think that more documentation around this would be good in many
respects...

1. Documenting these sorts of things frames understanding for others, which
can lead to more eyes on the implementation, which is always good
2. It'll make it easier for people to write custom VM's, which is only a
good thing for Erlang. For the JVM, for example, this is a huge benefit and
as Java the language dies, the ecosystem of budding JVM languages will no
doubt go strong
3. It'll make it easier for people to compile things to BEAM, which only
goes to show that Erlang's underbelly is general purpose and useful for
building robust, fault-tolerant software

I realize that it'd be a lot of someone's time, but I want to say that it'd
probably be a really good endeavor for the community. I think there are a
lot of smart people that aren't full time VM or language architects who
still can probably do interesting things if they have some guidance on what
is going on with BEAM.
Jon

2012/5/7 Richard O'Keefe <ok@REDACTED>

>
> On 8/05/2012, at 5:35 PM, Michael Turner wrote:
>
> > "(b) We learn only at the end of those 5 pages that there are
> > really TWO different things called BEAM:
> >       - the 'high level abstract instructions' generated
> >         by the compiler, which is pretty stable, and
> >       - the 'internal form' meant for execution, generated
> >         by the loader, which 'has changed many times'."
> >
> > Then there's the recommendation I read somewhere (I believe by a HiPE
> > implementor) that it makes more sense to target Core Erlang. So, in a
> > way, there are three levels you could target, two of them plausibly
> > called "BEAM".
>
> If you want to compile an extended syntax into something that is
> already supported in Core Erlang, no worries.  For example,
> implementing list comprehensions with out-of-line code, as
> currently done, could be done that way.
>
> If you want to compile list comprehensions into inline code,
> I believe it can be done using high-level BEAM, but you can't
> do it through Core Erlang.
>
> If you want to compile something like frames, you need to
>  - extend HiPE if you want the new feature to go fast *and*
>  - extend low level BEAM *and*
>  - extend high level BEAM *and*
>  - extend Core Erlang *and*
>  - extend source Erlang (probably the easiest step) *and*
>  - extend the AST form (not too hard) *and*
>  - extend the tools that process the AST form *and*
>  - last but very much not least, you need to
>   extend the documentation.
>
> The more levels you have the harder it gets, unless the design
> is very modular.  Here I will say that Quintus never really
> got this as organised as they should have.  Adding a new
> instruction required editing upwards of a dozen files.
>
> The nearest I've seen to a well-structured emulator was the
> Icon one, where the various C files that were used were generated
> from an annotated master.
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120508/3527fe4b/attachment.htm>