[gPXE-devel] Control Flow (Flow of Control)

[Shao Miller]

I should have changed the subject title.  Sorry!

Shao Miller wrote:
> Stefan Hajnoczi wrote:
>>
>> =Control Flow=
>>
>> ...Although the structured approach is more user-friendly, the low-level
>> approach is reasonably usable and meets our code size requirements to
>> fit into a 64 KB ROM more readily...
>>
>
> Personally, I'd like to see gPXE scripting Turing-complete.  Then the 
> user can implement their favourite video game, even if they can't use 
> it as a video game. :)  For the two constraints above:
> - User-friendly
> - Low cost-size cost
>
> We could potentially benefit by putting the code-size cost onus on the 
> script.  A "standard library" could be developed, which users 
> _who_want_it_ can include it in their script or call it or whatever.  
> Minimally, gPXE would then need just enough additions to allow for the 
> scripting language itself to be usefully extended into a complete and 
> user-friendly system.
>
> Something that might come in handy might be "aliases," where something 
> can appear to be a command, but is really a substitution for something 
> else.  Here's a patch which provides such[1].  For example, you can do:
>
>    gPXE> set echo echo
>    gPXE> set hello hello
>    gPXE> set __foo:hex ${echo:hex}:20:${hello:hex}
>    gPXE> foo
>    hello
>
> Then we might get into things like wanting to call/return and passing 
> arguments.  The point is that if you can extend the language from 
> within the language, you can push the code size burden onto the script 
> and not gPXE, but also provide a user-friendly interface (even 
> different flavours!).
>
> A possible way to extend the language is by having a minimal 
> "dot-language":
>
>    gPXE> . +
>    gPXE> . -
>    gPXE> # Choose your stack
>    gPXE> . working_setting
>    gPXE> # Copy a setting (stack)
>    gPXE> . from_setting to_setting
>    gPXE> . command_to_define : expansion
>    gPXE> . condition_setting ? true_command
>    gPXE> . condition_setting ! else_command
>
> etc.  My hope would be that parsing code cost could be minimized with 
> something like, though extending the language from within the language 
> is just an idea to share, not a recommendation.
>
>> ...I therefore support getting
>> if/goto into gPXE - it will allow a wider audience to do
>> boot.kernel.org-style magic.
>>
>
> Agreed.  'if' functionality can be roughly matched without being 
> implemented in gPXE code, but is ugly and quirky, so an in-code 
> implementation would be nice.  I like yours, Stefan. :)
>
> - Shao Miller
>
> [1] 
> http://git.etherboot.org/?p=people/sha0/gpxe.git;a=commitdiff;h=582e0eb41454b5ce15367fa39964369d9aa0aee9 
>
>