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.<div>
<br></div><div>I think that more documentation around this would be good in many respects...</div><div><br></div><div>1. Documenting these sorts of things frames understanding for others, which can lead to more eyes on the implementation, which is always good</div>
<div>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</div>
<div>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</div><div><br></div><div>
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.</div>
<div>Jon<br><br><div class="gmail_quote">2012/5/7 Richard O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On 8/05/2012, at 5:35 PM, Michael Turner wrote:<br>
<br>
> "(b) We learn only at the end of those 5 pages that there are<br>
> really TWO different things called BEAM:<br>
> - the 'high level abstract instructions' generated<br>
> by the compiler, which is pretty stable, and<br>
> - the 'internal form' meant for execution, generated<br>
> by the loader, which 'has changed many times'."<br>
><br>
> Then there's the recommendation I read somewhere (I believe by a HiPE<br>
> implementor) that it makes more sense to target Core Erlang. So, in a<br>
> way, there are three levels you could target, two of them plausibly<br>
> called "BEAM".<br>
<br>
</div>If you want to compile an extended syntax into something that is<br>
already supported in Core Erlang, no worries. For example,<br>
implementing list comprehensions with out-of-line code, as<br>
currently done, could be done that way.<br>
<br>
If you want to compile list comprehensions into inline code,<br>
I believe it can be done using high-level BEAM, but you can't<br>
do it through Core Erlang.<br>
<br>
If you want to compile something like frames, you need to<br>
- extend HiPE if you want the new feature to go fast *and*<br>
- extend low level BEAM *and*<br>
- extend high level BEAM *and*<br>
- extend Core Erlang *and*<br>
- extend source Erlang (probably the easiest step) *and*<br>
- extend the AST form (not too hard) *and*<br>
- extend the tools that process the AST form *and*<br>
- last but very much not least, you need to<br>
extend the documentation.<br>
<br>
The more levels you have the harder it gets, unless the design<br>
is very modular. Here I will say that Quintus never really<br>
got this as organised as they should have. Adding a new<br>
instruction required editing upwards of a dozen files.<br>
<br>
The nearest I've seen to a well-structured emulator was the<br>
Icon one, where the various C files that were used were generated<br>
from an annotated master.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>