It could probably be done. That does not mean it should be done.<div><br></div><div>The preloaded files during development are a pain as it is. Please do not add to it =D</div><div><br></div><div>// Björn-Egil<br><br><div class="gmail_quote">
2012/5/14 Anthony Ramine <span dir="ltr"><<a href="mailto:n.oxyde@gmail.com" target="_blank">n.oxyde@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There is already a chicken-and-egg problem, that's why there are some BEAM files<br>
in the Git repository, look in erts/preloaded/ebin.<br>
<br>
Nothing prevents us from generating these C files from some Erlang code and<br>
versioning them in Git too. This way the system would be bootstrapped from the<br>
previously generated files in the repository.<br>
<br>
--<br>
Anthony Ramine<br>
<br>
<br>
<br>
<br>
Le 14 mai 2012 à 15:08, Bengt Kleberg a écrit :<br>
<div class="HOEnZb"><div class="h5"><br>
> Greetings,<br>
><br>
> Perhaps there is a chicken-and-egg problem with requiring Erlang to<br>
> generate files used to build Erlang?<br>
><br>
><br>
> bengt<br>
><br>
> On Mon, 2012-05-14 at 15:02 +0200, Anthony Ramine wrote:<br>
>> Couldn't some of the bootstrap Perl scripts like beam_makeops and make_tables be<br>
>> rewritten and documented in Erlang? I think it would make things more obvious if<br>
>> they were not obscure Perl scripts without comments. Furthermore it would make<br>
>> Erlang/OTP eat more of its own dog food.<br>
>><br>
>> The only thing that would need to be changed with regard to the bootstrap itself<br>
>> is that their output would have to be versioned just as the erts/preloaded/ BEAM<br>
>> files. A new command should also be added to otp_build to update them.<br>
>><br>
>> Some of these generated files are:<br>
>><br>
>> beam_tr_funcs.h<br>
>> beam_pred_funcs.h<br>
>> beam_hot.h<br>
>> beam_cold.h<br>
>> beam_opcodes.c<br>
>> beam_opcodes.h<br>
>> beam_opcodes.erl<br>
>> beam_opcodes.hrl<br>
>> erl_am.c<br>
>> erl_bif_table.c<br>
>> erl_bif_wrap.c<br>
>> erl_pbifs.c<br>
>> erl_atom_table.h<br>
>> erl_bif_table.h<br>
>><br>
>> There may be an obvious reason for them not to be generated by Erlang itself but<br>
>> I'm not aware of it.<br>
>><br>
>> Regards.<br>
>><br>
>> --<br>
>> Anthony Ramine<br>
>><br>
>> Le 9 mai 2012 à 01:58, Richard O'Keefe a écrit :<br>
>><br>
>>> Let me illustrate the Icon approach by showing you a fragment of the<br>
>>> micro-BEAM I wrote to get the performance numbers in the frames proposal.<br>
>>> (The whole thing is fragmentary.)<br>
>>><br>
>>> ...<br>
>>> @i<br>
>>> max src, snd, dst<br>
>>> @d<br>
>>> dst := max(src, snd)<br>
>>><br>
>>> This computes the maximum using the micro-Erlang term ordering.<br>
>>> If src and snd are tagged immediate integers the comparison is<br>
>>> done inline; the compare() function is called otherwise.<br>
>>> @c<br>
>>> T = @src;<br>
>>> U = @snd;<br>
>>> @dst = cmp(T, >, U) ? T : U;<br>
>>> @step;<br>
>>> @e<br>
>>> ...<br>
>>> @i<br>
>>> check_record src, size, const<br>
>>> @d<br>
>>> Type test.<br>
>>><br>
>>> Fail unless src is tagged as a pointer to a tuple or frame,<br>
>>> the first word it points to is size, and the second is the<br>
>>> const (which must be an atom, but we don't check that).<br>
>>> Used for record matching.<br>
>>> @c<br>
>>> T = @src;<br>
>>> if (!is_tuple(T)) @fail "is_record"; else<br>
>>> if (FIELD(T, TUP_TAG, 0) != @size) @fail "is_record"; else<br>
>>> if (FIELD(T, TUP_TAG, 1) != @const) @fail "is_record"; else<br>
>>> @step;<br>
>>> @e<br>
>>> ...<br>
>>> There is a preprocessor written in AWK that turns this into<br>
>>> several C files. One of them is the emulator cases. For<br>
>>> the check_record instruction you get<br>
>>><br>
>>> #line 75 "frame.master"<br>
>>> case CHECK_RECORD:<br>
>>> #line 76 "frame.master"<br>
>>> T = reg[(int)P[1]];<br>
>>> #line 77 "frame.master"<br>
>>> if (!is_tuple(T))<br>
>>> P = failure, operation = "is_record"; else<br>
>>> #line 78 "frame.master"<br>
>>> if (FIELD(T, TUP_TAG, 0) != 4)<br>
>>> P = failure, operation = "is_record"; else<br>
>>> #line 79 "frame.master"<br>
>>> if (FIELD(T, TUP_TAG, 1) != P[3])<br>
>>> P = failure, operation = "is_record"; else<br>
>>> #line 80 "frame.master"<br>
>>> P += 4;<br>
>>> break;<br>
>>><br>
>>> where I've broken the long lines (the preprocessor doesn't).<br>
>>> The #line directives are option.<br>
>>><br>
>>> @i introduces an instruction; the next line is a template<br>
>>> for it saying what the operands are.<br>
>>> @d introduces the description for people.<br>
>>> @c introduces the code. In it, various built-in @macros<br>
>>> are expanded.<br>
>>><br>
>>> One advantage of doing it this way is that by using<br>
>>> @step to update the PC I *cannot* get the offset wrong;<br>
>>> the preprocessor counted the operands and their sizes<br>
>>> for me. Similarly, what I write has *no* operand numbers;<br>
>>> the preprocessor counted those, and supplies all necessary<br>
>>> casts as well. I can shuffle operands around (in @i)<br>
>>> without revising the code (in @c), and have.<br>
>>><br>
>>> It wouldn't be too hard to write another preprocessor that<br>
>>> built some kind of documentation (HTML would probably be<br>
>>> easiest) out of this, but since this was an experiment,<br>
>>> it didn't seem worth while.<br>
>>><br>
>>> Why did I write the preprocessor?<br>
>>> Well, to be honest, the first draft didn't use one.<br>
>>> I got a bit sick of debugging, and wrote the preprocessor<br>
>>> (based on vague memories of Icon) to eliminate a class of<br>
>>> errors. It turned out to be _easier_ to develop a<br>
>>> documented emulator than an undocumented one.<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>
>><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>
><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>
<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>