[SCM] Lisaac compiler branch, master, updated. lisaac-0.12-627-gd87beee
ontologiae
ontologiae at gmail.com
Fri May 28 11:14:36 UTC 2010
The following commit has been merged in the master branch:
commit d87beee1c76b5cbaaf03951fc7e9e75722400c4c
Author: ontologiae <ontologiae at gmail.com>
Date: Fri May 28 11:37:05 2010 +0200
Hacking file in html
diff --git a/src/HACKING b/src/HACKING
index de8e773..a43b255 100644
--- a/src/HACKING
+++ b/src/HACKING
@@ -24,7 +24,8 @@ Found in `ANY`.
- `list_main:LIST` is the list of the `main()` function.
- `profil_current:PROFIL`: the profil being executed in the current execution
- pass
+ pass.
+%PA : c'est quoi PROFIL
- `seq_list:FAST_ARRAY(LIST)`: the list hierarchy during the execute pass.
First comes the containing lists and then the contained lists. This is sort of
diff --git a/src/HACKING.html b/src/HACKING.html
new file mode 100644
index 0000000..3e05352
--- /dev/null
+++ b/src/HACKING.html
@@ -0,0 +1,468 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
+"http://www.w3.org/TR/html4/loose.dtd">
+
+<html>
+<head>
+ <meta name="generator" content="HTML Tidy for Mac OS X (vers 31 October 2006 - Apple Inc. build 13), see www.w3.org">
+
+ <title>~/Documents/Projet IsaacOS/GIT/compiler/src/HACKING.html</title>
+ <meta name="Generator" content="Vim/7.2">
+ <meta http-equiv="content-type" content="text/html; charset=us-ascii">
+ <style type="text/css">
+body {
+ background-color: #FFFFFF;
+ color: #000000;
+ }
+ h3.c4 {font-family: monospace}
+ span.c3 {font-family: monospace}
+ span.c2 {background-color: #e6e6e6}
+ span.c1 {color: #888888}
+ </style>
+</head>
+
+<body>
+ <span class="c3"><span class="c2"><span class="c1"> 1</span></span> A Guide to Hacking in the Compiler Source<br>
+ <span class="c2"><span class="c1"> 2</span></span> =========================================<br>
+ <span class="c2"><span class="c1"> 3</span></span><br>
+ <span class="c2"><span class="c1"> 4</span></span> You can generate the type hierarchy using the script `src/hierarchy.sh`<br>
+ <span class="c2"><span class="c1"> 5</span></span><br>
+ <span class="c2"><span class="c1"> 6</span></span> Questions to Benoît<br>
+ <span class="c2"><span class="c1"> 7</span></span> ===================<br>
+ <span class="c2"><span class="c1"> 8</span></span><br>
+ <span class="c2"><span class="c1"> 9</span></span> - Why `&` and `|` are duplicated in `EXPR_AND_LOGIC`, `EXPR_AND`,<br>
+ <span class="c2"><span class="c1"> 10</span></span> `EXPR_OR_LOGIC` and `EXPR_OR`. Is that for optimization purposes knowing
+ that<br>
+ <span class="c2"><span class="c1"> 11</span></span> the logic AND might not have to keep the exact result of the arithmetic
+ AND?<br>
+ <span class="c2"><span class="c1"> 12</span></span><br>
+ <span class="c2"><span class="c1"> 13</span></span> - Why no postcondition in `<a href="#LIST">LIST</a>.execute` ?<br>
+ <span class="c2"><span class="c1"> 14</span></span><br>
+ <span class="c2"><span class="c1"> 15</span></span> [ // make sure <a href=
+ "#LIST">LIST</a>.execute return a list<br>
+ <span class="c2"><span class="c1"> 16</span></span> +? { + l:<a href=
+ "#LIST">LIST</a>; l ?= Result != NULL };<br>
+ <span class="c2"><span class="c1"> 17</span></span> ]<br>
+ <span class="c2"><span class="c1"> 18</span></span><br>
+ <span class="c2"><span class="c1"> 19</span></span> Global Variables<br>
+ <span class="c2"><span class="c1"> 20</span></span> ================<br>
+ <span class="c2"><span class="c1"> 21</span></span><br>
+ <span class="c2"><span class="c1"> 22</span></span> Found in `ANY`.<br>
+ <span class="c2"><span class="c1"> 23</span></span><br>
+ <span class="c2"><span class="c1"> 24</span></span> - `list_main:<a href="#LIST">LIST</a>` is the list of the `main()` function.<br>
+ <span class="c2"><span class="c1"> 25</span></span><br>
+ <span class="c2"><span class="c1"> 26</span></span> - `profil_current:<a href="#profil">PROFIL</a>`: the profil being executed in the current
+ execution<br>
+ <span class="c2"><span class="c1"> 27</span></span> pass.<br>
+ <span class="c2"><span class="c1"> 28</span></span> %PA : c'est quoi <a href="#profil">PROFIL</a><br>
+ <span class="c2"><span class="c1"> 29</span></span><br>
+ <span class="c2"><span class="c1"> 30</span></span> - `seq_list:FAST_ARRAY(<a href="#LIST">LIST</a>)`: the list hierarchy during the execute
+ pass.<br>
+ <span class="c2"><span class="c1"> 31</span></span> First comes the containing lists and then the contained lists. This is sort
+ of<br>
+ <span class="c2"><span class="c1"> 32</span></span> a stack trace.<br>
+ <span class="c2"><span class="c1"> 33</span></span><br>
+ <span class="c2"><span class="c1"> 34</span></span> - `list_current:<a href="#LIST">LIST</a>`: the current list being executed. This is not
+ always the<br>
+ <span class="c2"><span class="c1"> 35</span></span> last element of `seq_list` as when a `<a href="#profil">PROFIL</a>` is
+ executed, the `list_current`<br>
+ <span class="c2"><span class="c1"> 36</span></span> is reset to `NULL`.<br>
+ <span class="c2"><span class="c1"> 37</span></span><br>
+ <span class="c2"><span class="c1"> 38</span></span> - `modify_count:INTEGER`: How many times a new pass was requested during the<br>
+ <span class="c2"><span class="c1"> 39</span></span> current pass.<br>
+ <span class="c2"><span class="c1"> 40</span></span><br>
+ <span class="c2"><span class="c1"> 41</span></span><br>
+ <span class="c2"><span class="c1"> 42</span></span> Passes<br>
+ <span class="c2"><span class="c1"> 43</span></span> ======<br>
+ <span class="c2"><span class="c1"> 44</span></span><br>
+ <span class="c2"><span class="c1"> 45</span></span> Passes can be found in `PROTOTYPE.depend`. The passes continues until<br>
+ <span class="c2"><span class="c1"> 46</span></span> `modify_count` hasn't increased in the pass.<br>
+ <span class="c2"><span class="c1"> 47</span></span><br>
+ <span class="c2"><span class="c1"> 48</span></span> Depending Pass<br>
+ <span class="c2"><span class="c1"> 49</span></span> --------------<br>
+ <span class="c2"><span class="c1"> 50</span></span><br>
+ <span class="c2"><span class="c1"> 51</span></span> This is where all the parsing happens and all the abstract syntax tree (AST) is<br>
+ <span class="c2"><span class="c1"> 52</span></span> generated.<br>
+ <span class="c2"><span class="c1"> 53</span></span><br>
+ <span class="c2"><span class="c1"> 54</span></span> Main code in `NODE.extend_pass`. This will walk through all the `NODE_TYPE`s<br>
+ <span class="c2"><span class="c1"> 55</span></span> and `update` them. A `NODE_TYPE` is a possible polymorphic call that need<br>
+ <span class="c2"><span class="c1"> 56</span></span> resolution. If the `update` return `TRUE`, it means that the node no longer need<br>
+ <span class="c2"><span class="c1"> 57</span></span> to be updated and can be skipped from the depending pass next time.<br>
+ <span class="c2"><span class="c1"> 58</span></span><br>
+ <span class="c2"><span class="c1"> 59</span></span> Executing Pass<br>
+ <span class="c2"><span class="c1"> 60</span></span> --------------<br>
+ <span class="c2"><span class="c1"> 61</span></span><br>
+ <span class="c2"><span class="c1"> 62</span></span> Recursive executing pass is in `<a href="#profil">PROFIL</a>_<a href=
+ "#LIST">LIST</a>.execute_pass_recursive`<br>
+ <span class="c2"><span class="c1"> 63</span></span><br>
+ <span class="c2"><span class="c1"> 64</span></span> Main code in `<a href="#profil">PROFIL</a>_<a href="#LIST">LIST</a>.execute` with some
+ code before and after in<br>
+ <span class="c2"><span class="c1"> 65</span></span> `PROTOTYPE.depend` to cleanup before a new pass or check something that would<br>
+ <span class="c2"><span class="c1"> 66</span></span> trigger a new pass.<br>
+ <span class="c2"><span class="c1"> 67</span></span><br>
+ <span class="c2"><span class="c1"> 68</span></span> `<a href="#profil">PROFIL</a>_<a href="#LIST">LIST</a>` contain all profils for slots
+ generated. They are ordered with the<br>
+ <span class="c2"><span class="c1"> 69</span></span> profils that are alive first, and the dead profils last. There are three<br>
+ <span class="c2"><span class="c1"> 70</span></span> categories of profils:<br>
+ <span class="c2"><span class="c1"> 71</span></span> - the profils that are always alive (`Section External`) below `life_limit_base`<br>
+ <span class="c2"><span class="c1"> 72</span></span> - the profils alive for the current executing pass below `life_limit`<br>
+ <span class="c2"><span class="c1"> 73</span></span> - the dead profils with an index greater or equal to `life_limit`.<br>
+ <span class="c2"><span class="c1"> 74</span></span><br>
+ <span class="c2"><span class="c1"> 75</span></span> A standard execution pass is like this:<br>
+ <span class="c2"><span class="c1"> 76</span></span><br>
+ <span class="c2"><span class="c1"> 77</span></span> 1. First, all profils alive from the previous pass are marked dead (lower<br>
+ <span class="c2"><span class="c1"> 78</span></span> `life_limit` to `life_limit_base`)<br>
+ <span class="c2"><span class="c1"> 79</span></span> 2. It call `execute` on `list_main`<br>
+ <span class="c2"><span class="c1"> 80</span></span> 3. For the profils (`profil_current`) that were marked alive during the previous<br>
+ <span class="c2"><span class="c1"> 81</span></span> step, it call `execute` on them.<br>
+ <span class="c2"><span class="c1"> 82</span></span> 4. Clean the dead profils.<br>
+ <span class="c2"><span class="c1"> 83</span></span> 5. Determine if there is a need for a new executing pass.<br>
+ <span class="c2"><span class="c1"> 84</span></span><br>
+ <span class="c2"><span class="c1"> 85</span></span> A recursive execution pass has `<a href="#profil">PROFIL</a>.mode_recursive` to `TRUE` and
+ is similar<br>
+ <span class="c2"><span class="c1"> 86</span></span> to a normal execution pass, with some differences.<br>
+ <span class="c2"><span class="c1"> 87</span></span><br>
+ <span class="c2"><span class="c1"> 88</span></span> Code Generation<br>
+ <span class="c2"><span class="c1"> 89</span></span> ---------------<br>
+ <span class="c2"><span class="c1"> 90</span></span><br>
+ <span class="c2"><span class="c1"> 91</span></span> Generate function signatures: `<a href="#profil">PROFIL</a>_<a href=
+ "#LIST">LIST</a>.genere_handler`<br>
+ <span class="c2"><span class="c1"> 92</span></span><br>
+ <span class="c2"><span class="c1"> 93</span></span> Generate the `main()` source code: `<a href="#LIST">LIST</a>.genere_extern`<br>
+ <span class="c2"><span class="c1"> 94</span></span><br>
+ <span class="c2"><span class="c1"> 95</span></span> Generate functions: `<a href="#profil">PROFIL</a>_<a href="#LIST">LIST</a>.genere`<br>
+ <span class="c2"><span class="c1"> 96</span></span><br>
+ <span class="c2"><span class="c1"> 97</span></span> Abstract Syntax Tree<br>
+ <span class="c2"><span class="c1"> 98</span></span> ====================<br>
+ <span class="c2"><span class="c1"> 99</span></span><br>
+ <span class="c2"><span class="c1">100</span></span> The objects descending from `ITM_CODE` and `ITM_ARGUMENT` and `ITM_TYPE` and<br>
+ <span class="c2"><span class="c1">101</span></span> more generally, all items in the `item` directory form the abstract syntax tree.<br>
+ <span class="c2"><span class="c1">102</span></span><br>
+ <span class="c2"><span class="c1">103</span></span> # `ITM_ARGUMENT` #<br>
+ <span class="c2"><span class="c1">104</span></span><br>
+ <span class="c2"><span class="c1">105</span></span> - `ITM_ARGUMENT` (`item`)<br>
+ <span class="c2"><span class="c1">106</span></span> - `ITM_ARG` (`item`)<br>
+ <span class="c2"><span class="c1">107</span></span> - `ITM_ARGS` (`item`)<br>
+ <span class="c2"><span class="c1">108</span></span><br>
+ <span class="c2"><span class="c1">109</span></span><br>
+ <span class="c2"><span class="c1">110</span></span> This represents an argument type list. This is a list of `ITM_TYPE_MONO` and is<br>
+ <span class="c2"><span class="c1">111</span></span> specialized in two versions. `ITM_ARG` contains only one type while `ITM_ARGS`<br>
+ <span class="c2"><span class="c1">112</span></span> can contain multiple types<br>
+ <span class="c2"><span class="c1">113</span></span><br>
+ <span class="c2"><span class="c1">114</span></span> # `ITM_CODE` #<br>
+ <span class="c2"><span class="c1">115</span></span><br>
+ <span class="c2"><span class="c1">116</span></span> - `ITM_CODE` (`item`)<br>
+ <span class="c2"><span class="c1">117</span></span> - `ITM_<a href="#LIST">LIST</a>` (`item`)<br>
+ <span class="c2"><span class="c1">118</span></span> - `ITM_BLOCK` (`item`)<br>
+ <span class="c2"><span class="c1">119</span></span> - `ITM_RESULT` (`item`)<br>
+ <span class="c2"><span class="c1">120</span></span> - `ITM_BINARY` (`item`)<br>
+ <span class="c2"><span class="c1">121</span></span> - `ITM_OLD` (`item`)<br>
+ <span class="c2"><span class="c1">122</span></span> - `ITM_LDOTS` (`item`)<br>
+ <span class="c2"><span class="c1">123</span></span> - `ITM_EXPRESSION` (`item`)<br>
+ <span class="c2"><span class="c1">124</span></span> - `ITM_OPERATOR` (`item`)<br>
+ <span class="c2"><span class="c1">125</span></span> - `ITM_<a href="#LIST">LIST</a>_IDF` (`item`)<br>
+ <span class="c2"><span class="c1">126</span></span> - `ITM_READ` (`item`)<br>
+ <span class="c2"><span class="c1">127</span></span> - `ITM_READ_ARG1` (`item`)<br>
+ <span class="c2"><span class="c1">128</span></span> - `ITM_READ_ARGS` (`item`)<br>
+ <span class="c2"><span class="c1">129</span></span> - `ITM_READ_ARG2` (`item`)<br>
+ <span class="c2"><span class="c1">130</span></span> - `ITM_EXTERN` (`item`)<br>
+ <span class="c2"><span class="c1">131</span></span> - `ITM_EXTERNAL` (`item`)<br>
+ <span class="c2"><span class="c1">132</span></span> - `ITM_EXTERNAL_TYPE` (`item`)<br>
+ <span class="c2"><span class="c1">133</span></span> - `ITM_WRITE` (`item`)<br>
+ <span class="c2"><span class="c1">134</span></span> - `ITM_WRITE_CAST` (`item`)<br>
+ <span class="c2"><span class="c1">135</span></span> - `ITM_WRITE_VALUE` (`item`)<br>
+ <span class="c2"><span class="c1">136</span></span> - `ITM_WRITE_CODE` (`item`)<br>
+ <span class="c2"><span class="c1">137</span></span> - `ITM_CONSTANT` (`item`)<br>
+ <span class="c2"><span class="c1">138</span></span> - `ITM_PROTOTYPE` (`item`)<br>
+ <span class="c2"><span class="c1">139</span></span> - `ITM_REAL` (`item`)<br>
+ <span class="c2"><span class="c1">140</span></span> - `ITM_CHARACTER` (`item`)<br>
+ <span class="c2"><span class="c1">141</span></span> - `ITM_STRING` (`item`)<br>
+ <span class="c2"><span class="c1">142</span></span> - `ITM_NUMBER` (`item`)<br>
+ <span class="c2"><span class="c1">143</span></span><br>
+ <span class="c2"><span class="c1">144</span></span> This represents a bit of code in the AST. It can be transformed in code_life<br>
+ <span class="c2"><span class="c1">145</span></span> objects (instructions and expressions) using the `to_run` for instructions and<br>
+ <span class="c2"><span class="c1">146</span></span> `to_run_expr` for expressions.<br>
+ <span class="c2"><span class="c1">147</span></span><br>
+ <span class="c2"><span class="c1">148</span></span> The default behaviour of `to_run` is to return the expression from `to_run_expr`<br>
+ <span class="c2"><span class="c1">149</span></span> as an instruction is an instruction (`EXPR` inherit from `INSTR`).<br>
+ <span class="c2"><span class="c1">150</span></span><br>
+ <span class="c2"><span class="c1">151</span></span> # `ITM_TYPE` #<br>
+ <span class="c2"><span class="c1">152</span></span><br>
+ <span class="c2"><span class="c1">153</span></span> - `ITM_TYPE` (`item`)<br>
+ <span class="c2"><span class="c1">154</span></span> - `ITM_TYPE_MULTI` (`item`)<br>
+ <span class="c2"><span class="c1">155</span></span> - `ITM_TYPE_MONO` (`item`)<br>
+ <span class="c2"><span class="c1">156</span></span> - `ITM_TYPE_GENERIC_ELT` (`item`)<br>
+ <span class="c2"><span class="c1">157</span></span> - `ITM_TYPE_BLOCK` (`item`)<br>
+ <span class="c2"><span class="c1">158</span></span> - `ITM_TYPE_SIMPLE` (`item`)<br>
+ <span class="c2"><span class="c1">159</span></span> - `ITM_TYPE_PARAMETER`
+ (`item`)<br>
+ <span class="c2"><span class="c1">160</span></span> - `ITM_TYPE_STYLE`
+ (`item`)<br>
+ <span class="c2"><span class="c1">161</span></span>
+ - `ITM_TYPE_GENERIC` (`item`)<br>
+ <span class="c2"><span class="c1">162</span></span><br>
+ <span class="c2"><span class="c1">163</span></span><br>
+ <span class="c2"><span class="c1">164</span></span> Dynamic Binding<br>
+ <span class="c2"><span class="c1">165</span></span> ===============<br>
+ <span class="c2"><span class="c1">166</span></span><br>
+ <span class="c2"><span class="c1">167</span></span> Dynamic binding is chen a slot is called and the receiver is of a polymorphic<br>
+ <span class="c2"><span class="c1">168</span></span> type. We have to generate a `switch` C statement to choose which implementation<br>
+ <span class="c2"><span class="c1">169</span></span> to use.<br>
+ <span class="c2"><span class="c1">170</span></span><br>
+ <span class="c2"><span class="c1">171</span></span> When a call to a slot is converted from the AST to code life in<br>
+ <span class="c2"><span class="c1">172</span></span> `ITM_READ.to_run_expr`, it creates a `NODE_TYPE` instruction using<br>
+ <span class="c2"><span class="c1">173</span></span> `NODE.new_read`. At this stage, the node is not yet ready for the execution<br>
+ <span class="c2"><span class="c1">174</span></span> pass and need updates from the depending passes. Updating is divided in<br>
+ <span class="c2"><span class="c1">175</span></span> `update_case` and `update_depth`.<br>
+ <span class="c2"><span class="c1">176</span></span><br>
+ <span class="c2"><span class="c1">177</span></span> `update_case`, beside handling special case for booleans and `Expanded`, will<br>
+ <span class="c2"><span class="c1">178</span></span> ask the dispatching `expr`ession for the list of possible runtime types using<br>
+ <span class="c2"><span class="c1">179</span></span> `EXPR.get_type`. Then for each type, it will ask the `data` (`DTA`) to produce<br>
+ <span class="c2"><span class="c1">180</span></span> a list for a special dynamic type. Then the list is inserted in the `switch`.<br>
+ <span class="c2"><span class="c1">181</span></span> As a special case, if the list of dynamic types is empty, don't generate a<br>
+ <span class="c2"><span class="c1">182</span></span> switch. If it contains only one type, only store the list generated by the<br>
+ <span class="c2"><span class="c1">183</span></span> `data` and don't bother with a `switch`.<br>
+ <span class="c2"><span class="c1">184</span></span><br>
+ <span class="c2"><span class="c1">185</span></span> The list generated by the `data` might contains other nodes for further<br>
+ <span class="c2"><span class="c1">186</span></span> dispatching. For instance, it can contain a `NODE_STYLE` to dispatch between<br>
+ <span class="c2"><span class="c1">187</span></span> different versions of the same code slot (in case the slot has been written<br>
+ <span class="c2"><span class="c1">188</span></span> to). `update_depth` role is to call `data.update_branch` on each of the lists<br>
+ <span class="c2"><span class="c1">189</span></span> generated by the `data`. The `data` will then take care of updating further<br>
+ <span class="c2"><span class="c1">190</span></span> nodes it created. The `type_self` given is either the `type_self` already given<br>
+ <span class="c2"><span class="c1">191</span></span> or if `NULL`, the dynamic type.<br>
+ <span class="c2"><span class="c1">192</span></span><br>
+ <span class="c2"><span class="c1">193</span></span> `TYPE_NODE`, requires a non `NULL` `self_type` when updated (`update_link`).<br>
+ <span class="c2"><span class="c1">194</span></span> This type always corresponds to the dynamic type and us used to generate the<br>
+ <span class="c2"><span class="c1">195</span></span> `CALL_SLOT` instruction, dispatching on the differents possible slot<br>
+ <span class="c2"><span class="c1">196</span></span> implementations.<br>
+ <span class="c2"><span class="c1">197</span></span><br>
+ <span class="c2"><span class="c1">198</span></span> # `NODE` #<br>
+ <span class="c2"><span class="c1">199</span></span><br>
+ <span class="c2"><span class="c1">200</span></span> - `NODE` (`dispatcher`)<br>
+ <span class="c2"><span class="c1">201</span></span> - `NODE_TYPE` (`dispatcher`)<br>
+ <span class="c2"><span class="c1">202</span></span> - `NODE_STYLE` (`dispatcher`)<br>
+ <span class="c2"><span class="c1">203</span></span><br>
+ <span class="c2"><span class="c1">204</span></span> A `NODE` is a slot call site that need dispatching.<br>
+ <span class="c2"><span class="c1">205</span></span><br>
+ <span class="c2"><span class="c1">206</span></span> `NODE_TYPE` dispatches polymorphic calls according to an `expr`ession dynamic<br>
+ <span class="c2"><span class="c1">207</span></span> type. The `data` is used to create the code `<a href="#LIST">LIST</a>` for each possible
+ dynamic<br>
+ <span class="c2"><span class="c1">208</span></span> type, and further dispatch the call using `NODE_STYLE`.<br>
+ <span class="c2"><span class="c1">209</span></span><br>
+ <span class="c2"><span class="c1">210</span></span> `NODE_STYLE` dispatches the slot call according to the different possible<br>
+ <span class="c2"><span class="c1">211</span></span> implementations of the slot. If the slot has only one implementation, this is<br>
+ <span class="c2"><span class="c1">212</span></span> just fine. In any case, it creates a `CALL_SLOT` instruction using the<br>
+ <span class="c2"><span class="c1">213</span></span> arguments supplied by the `data`.<br>
+ <span class="c2"><span class="c1">214</span></span><br>
+ <span class="c2"><span class="c1">215</span></span> The `count` value represents the number of possibilities for dispatching<br>
+ <span class="c2"><span class="c1">216</span></span> computed until now.<br>
+ <span class="c2"><span class="c1">217</span></span><br>
+ <span class="c2"><span class="c1">218</span></span> It has the following different states:<br>
+ <span class="c2"><span class="c1">219</span></span><br>
+ <span class="c2"><span class="c1">220</span></span> - `switch = NULL` and `first_code = NULL`: No code at all, dispatching on an<br>
+ <span class="c2"><span class="c1">221</span></span> empty set.<br>
+ <span class="c2"><span class="c1">222</span></span> - `switch = NULL` and `first_code != NULL`: The dispatching `expr`ession has<br>
+ <span class="c2"><span class="c1">223</span></span> only one possibility. Don't bother generating a `switch`.<br>
+ <span class="c2"><span class="c1">224</span></span> - `switch != NULL`: the `expr`ession has more than one dispatching possibility,<br>
+ <span class="c2"><span class="c1">225</span></span> the switch contains a `list` of `CASE` containing the code `<a href=
+ "#LIST">LIST</a>`s.<br>
+ <span class="c2"><span class="c1">226</span></span><br>
+ <span class="c2"><span class="c1">227</span></span><br>
+ <span class="c2"><span class="c1">228</span></span> Code Life<br>
+ <span class="c2"><span class="c1">229</span></span> =========<br>
+ <span class="c2"><span class="c1">230</span></span><br>
+ <span class="c2"><span class="c1">231</span></span> Code Life is a special representation of the source code that is losely related<br>
+ <span class="c2"><span class="c1">232</span></span> to the syntax and is the best form to perform optimizations.<br>
+ <span class="c2"><span class="c1">233</span></span><br>
+ <span class="c2"><span class="c1">234</span></span> # `INSTR` #<br>
+ <span class="c2"><span class="c1">235</span></span><br>
+ <span class="c2"><span class="c1">236</span></span> - `INSTR` (`code_life`)<br>
+ <span class="c2"><span class="c1">237</span></span> - `FORALL_DATA` (`external`)<br>
+ <span class="c2"><span class="c1">238</span></span> - `CALL_NULL` (`external`)<br>
+ <span class="c2"><span class="c1">239</span></span> - `PUT_TO` (`external`)<br>
+ <span class="c2"><span class="c1">240</span></span> - `LOOP_END` (`code_life`)<br>
+ <span class="c2"><span class="c1">241</span></span> - `COP_LOCK` (`code_life`)<br>
+ <span class="c2"><span class="c1">242</span></span> - `<a href="#LIST">LIST</a>` (`code_life`)<br>
+ <span class="c2"><span class="c1">243</span></span> - `CALL_SLOT` (`code_life`)<br>
+ <span class="c2"><span class="c1">244</span></span> - `PUSH` (`code_life`)<br>
+ <span class="c2"><span class="c1">245</span></span> - `COP_UNLOCK` (`code_life`)<br>
+ <span class="c2"><span class="c1">246</span></span> - `NOP` (`code_life`)<br>
+ <span class="c2"><span class="c1">247</span></span> - `LOOP` (`code_life`)<br>
+ <span class="c2"><span class="c1">248</span></span> - `SWITCH` (`code_life`)<br>
+ <span class="c2"><span class="c1">249</span></span> - `WRITE` (`code_life`)<br>
+ <span class="c2"><span class="c1">250</span></span> - `PUT_TO` (`external`)<br>
+ <span class="c2"><span class="c1">251</span></span> - `WRITE_SLOT` (`code_life`)<br>
+ <span class="c2"><span class="c1">252</span></span> - `WRITE_LOCAL` (`code_life`)<br>
+ <span class="c2"><span class="c1">253</span></span> - `WRITE_GLOBAL` (`code_life`)<br>
+ <span class="c2"><span class="c1">254</span></span> - `NODE` (`dispatcher`)<br>
+ <span class="c2"><span class="c1">255</span></span> - `NODE_TYPE` (`dispatcher`)<br>
+ <span class="c2"><span class="c1">256</span></span> - `NODE_STYLE` (`dispatcher`)<br>
+ <span class="c2"><span class="c1">257</span></span> - `EXPR` (`code_life`)<br>
+ <span class="c2"><span class="c1">258</span></span> - ...<br>
+ <span class="c2"><span class="c1">259</span></span><br>
+ <span class="c2"><span class="c1">260</span></span> This is an instruction. Instructions can be generated in the target language<br>
+ <span class="c2"><span class="c1">261</span></span> using the `genere` slot and they are subject to the execution pass through the<br>
+ <span class="c2"><span class="c1">262</span></span> `execute` slot.<br>
+ <span class="c2"><span class="c1">263</span></span><br>
+ <span class="c2"><span class="c1">264</span></span> When executed, an instruction returns a better version of itself as a return<br>
+ <span class="c2"><span class="c1">265</span></span> value, or return `NULL` in case it wishes to remove itself.<br>
+ <span class="c2"><span class="c1">266</span></span><br>
+ <span class="c2"><span class="c1">267</span></span> TODO: What is `remove` exactly?<br>
+ <span class="c2"><span class="c1">268</span></span><br>
+ <span class="c2"><span class="c1">269</span></span> # `EXPR` #<br>
+ <span class="c2"><span class="c1">270</span></span><br>
+ <span class="c2"><span class="c1">271</span></span> - `EXPR` (`code_life`)<br>
+ <span class="c2"><span class="c1">272</span></span> - `CAST` (`code_life`)<br>
+ <span class="c2"><span class="c1">273</span></span> - `RESULT` (`code_life`)<br>
+ <span class="c2"><span class="c1">274</span></span> - `EXPR_MULTIPLE` (`code_life`)<br>
+ <span class="c2"><span class="c1">275</span></span> - `READ` (`code_life`)<br>
+ <span class="c2"><span class="c1">276</span></span> - `READ_SLOT` (`code_life`)<br>
+ <span class="c2"><span class="c1">277</span></span> - `READ_LOCAL` (`code_life`)<br>
+ <span class="c2"><span class="c1">278</span></span> - `READ_GLOBAL` (`code_life`)<br>
+ <span class="c2"><span class="c1">279</span></span> - `EXTERNAL_C` (`external`)<br>
+ <span class="c2"><span class="c1">280</span></span> - `SIZE_OF` (`external`)<br>
+ <span class="c2"><span class="c1">281</span></span> - `GET_TYPE_ID` (`external`)<br>
+ <span class="c2"><span class="c1">282</span></span> - `ITEM` (`external`)<br>
+ <span class="c2"><span class="c1">283</span></span> - `IS_EXPANDED` (`external`)<br>
+ <span class="c2"><span class="c1">284</span></span> - `EXPR_BINARY_CMP` (`external/comparison`), contains basic operators
+ for<br>
+ <span class="c2"><span class="c1">285</span></span> `>=`, `>`, `<`, `<=`, `=`, `!=`<br>
+ <span class="c2"><span class="c1">286</span></span> - `EXPR_BINARY_LOGIC` (`external/logic`), contains basic operators
+ for<br>
+ <span class="c2"><span class="c1">287</span></span> `&`, `&&`, `|`, `||`<br>
+ <span class="c2"><span class="c1">288</span></span> - `EXPR_UNARY_LOGIC` (`external/logic`), contains basic operator
+ `!`<br>
+ <span class="c2"><span class="c1">289</span></span> - `EXPR_UNARY` (`external/arithmetic`), contains basic operator `~`
+ (not)<br>
+ <span class="c2"><span class="c1">290</span></span> and `-` (minus),<br>
+ <span class="c2"><span class="c1">291</span></span> - `EXPR_BINARY` (`external/arithmetic`), contains basic operator `^`
+ (xor),<br>
+ <span class="c2"><span class="c1">292</span></span> `%` (mod), `+`, `-`, `/`, `*`, `&`, `|`, `<<`,
+ `>>`<br>
+ <span class="c2"><span class="c1">293</span></span> - `CONSTANT` (`constant`)<br>
+ <span class="c2"><span class="c1">294</span></span> - `STRING_CST` (`constant`)<br>
+ <span class="c2"><span class="c1">295</span></span> - `PROTOTYPE_CST` (`constant`)<br>
+ <span class="c2"><span class="c1">296</span></span> - `CHARACTER_CST` (`constant`)<br>
+ <span class="c2"><span class="c1">297</span></span> - `INTEGER_CST` (`constant`)<br>
+ <span class="c2"><span class="c1">298</span></span> - `REAL_CST` (`constant`)<br>
+ <span class="c2"><span class="c1">299</span></span> - `NATIVE_ARRAY_CHARACTER_CST` (`constant`)<br>
+ <span class="c2"><span class="c1">300</span></span><br>
+ <span class="c2"><span class="c1">301</span></span><br>
+ <span class="c2"><span class="c1">302</span></span> This is an instruction and represents an expression. It does have a<br>
+ <span class="c2"><span class="c1">303</span></span> `static_type`. As for all instructions, it is subject to the excuting pass<br>
+ <span class="c2"><span class="c1">304</span></span> through the `execute` slot.<br>
+ <span class="c2"><span class="c1">305</span></span><br>
+ <span class="c2"><span class="c1">306</span></span> An instruction has two execution slots: `execute_link` and `execute_unlink`.<br>
+ <span class="c2"><span class="c1">307</span></span> When executed as an instruction (`execute` slot called) the expression unlinks<br>
+ <span class="c2"><span class="c1">308</span></span> itself for an instruction by itself do nothing useful.<br>
+ <span class="c2"><span class="c1">309</span></span><br>
+ <span class="c2"><span class="c1">310</span></span> Expressions are linked together in a tree structure, and linking or unlinking<br>
+ <span class="c2"><span class="c1">311</span></span> expressions propagate to children expressions. When an expression is found to be<br>
+ <span class="c2"><span class="c1">312</span></span> useful in a computation, `execute_link` is called. But when an expression value<br>
+ <span class="c2"><span class="c1">313</span></span> is not needed, `execute_unlink` is called instead.<br>
+ <span class="c2"><span class="c1">314</span></span><br>
+ <span class="c2"><span class="c1">315</span></span> When an expression is executed as an instruction, its value is not needed so it<br>
+ <span class="c2"><span class="c1">316</span></span> is unlinked. Still, if the expression has a side effect, it can choose to return<br>
+ <span class="c2"><span class="c1">317</span></span> an instruction as a result to `execute_unlink` or call<br>
+ <span class="c2"><span class="c1">318</span></span> `list_current.insert_before`.<br>
+ <span class="c2"><span class="c1">319</span></span><br>
+ <span class="c2"><span class="c1">320</span></span></span>
+
+ <h3 class="c4" id="LIST"># `LIST` #</h3><span class="c3"><br>
+ <span class="c2"><span class="c1">321</span></span><br>
+ <span class="c2"><span class="c1">322</span></span> This is a list of instructions (`INSTR`) and is itself an instruction. This can<br>
+ <span class="c2"><span class="c1">323</span></span> be either a list in Lisaac (in braces), a block (curly braces) or contract<br>
+ <span class="c2"><span class="c1">324</span></span> blocks (brackets). It has an embedded index that point to a specific<br>
+ <span class="c2"><span class="c1">325</span></span> instruction.<br>
+ <span class="c2"><span class="c1">326</span></span><br>
+ <span class="c2"><span class="c1">327</span></span> TODO: understand how the list return its expressions, given that they are<br>
+ <span class="c2"><span class="c1">328</span></span> expressions and not instructions, and that there can be more than one<br>
+ <span class="c2"><span class="c1">329</span></span> expression. Is it through `RESULT`?<br>
+ <span class="c2"><span class="c1">330</span></span><br>
+ <span class="c2"><span class="c1">331</span></span> When executed, it puts itself as `list_current` for the time of its execution<br>
+ <span class="c2"><span class="c1">332</span></span> and restore the old value afterwards. Then, for all the instructions it<br>
+ <span class="c2"><span class="c1">333</span></span> contains, it excutes the instruction and replace the new instruction (returned<br>
+ <span class="c2"><span class="c1">334</span></span> by `execute`) in the list.<br>
+ <span class="c2"><span class="c1">335</span></span><br>
+ <span class="c2"><span class="c1">336</span></span> The new list (which is the same but modified on the fly) is returned from the<br>
+ <span class="c2"><span class="c1">337</span></span> execution step except in the following optimizing cases:<br>
+ <span class="c2"><span class="c1">338</span></span><br>
+ <span class="c2"><span class="c1">339</span></span> - When there is a call on NULL, all following instructions are removed as they<br>
+ <span class="c2"><span class="c1">340</span></span> are not expected to be executed<br>
+ <span class="c2"><span class="c1">341</span></span> - When there is a `list_current` (a parent list). The list move all its<br>
+ <span class="c2"><span class="c1">342</span></span> instructions in the `list_current` just before the child list.<br>
+ <span class="c2"><span class="c1">343</span></span><br>
+ <span class="c2"><span class="c1">344</span></span></span>
+
+ <h3 class="c4" id="profil"># PROFIL` #</h3><span class="c3"><br>
+ <span class="c2"><span class="c1">345</span></span><br>
+ <span class="c2"><span class="c1">346</span></span> A profil inherit from `ANY` and is a function signature in C. It represents a<br>
+ <span class="c2"><span class="c1">347</span></span> slot in Lisaac that might be customized with generic parameters or for<br>
+ <span class="c2"><span class="c1">348</span></span> optimization purposes.<br>
+ <span class="c2"><span class="c1">349</span></span><br>
+ <span class="c2"><span class="c1">350</span></span> A profil can be living or dead in the `<a href="#profil">PROFIL</a>_<a href="#LIST">LIST</a>`.
+ Just look at the<br>
+ <span class="c2"><span class="c1">351</span></span> documentation on the executing pass for more information about `<a href=
+ "#profil">PROFIL</a>_<a href="#LIST">LIST</a>`.<br>
+ <span class="c2"><span class="c1">352</span></span><br>
+ <span class="c2"><span class="c1">353</span></span> A profil contains `code` which is a `<a href="#LIST">LIST</a>`. This is the implementation of
+ the<br>
+ <span class="c2"><span class="c1">354</span></span> function. When executed through the `execute` slot, it forward the message<br>
+ <span class="c2"><span class="c1">355</span></span> calling `code.execute`. And the resulting instruction has better to still be<br>
+ <span class="c2"><span class="c1">356</span></span> a `<a href="#LIST">LIST</a>`<br>
+ <span class="c2"><span class="c1">357</span></span><br>
+ <span class="c2"><span class="c1">358</span></span> `execute_recursive` is not called by `<a href="#profil">PROFIL</a>_<a href="#LIST">LIST</a>`
+ but by `<a href="#profil">PROFIL</a>.set_life`<br>
+ <span class="c2"><span class="c1">359</span></span> only when in a recursive pass.<br>
+ <span class="c2"><span class="c1">360</span></span><br>
+ <span class="c2"><span class="c1">361</span></span><br>
+ <span class="c2"><span class="c1">362</span></span> Types<br>
+ <span class="c2"><span class="c1">363</span></span> -----<br>
+ <span class="c2"><span class="c1">364</span></span><br>
+ <span class="c2"><span class="c1">365</span></span> There are many prototypes for types, they are expalined here:<br>
+ <span class="c2"><span class="c1">366</span></span><br>
+ <span class="c2"><span class="c1">367</span></span> - `ITM_TYPE` hierarchy: represent a type plus all that surround the type<br>
+ <span class="c2"><span class="c1">368</span></span> (`Strict`, `Expanded`, genericity, ...). This is only the name of the type in<br>
+ <span class="c2"><span class="c1">369</span></span> the AST.<br>
+ <span class="c2"><span class="c1">370</span></span><br>
+ <span class="c2"><span class="c1">371</span></span> - `ITM_PROTOTYPE`, `PROTOTYPE_CST`: is a constant reference value to the<br>
+ <span class="c2"><span class="c1">372</span></span> prototype itself respectively in the AST and code life.<br>
+ <span class="c2"><span class="c1">373</span></span><br>
+ <span class="c2"><span class="c1">374</span></span> - `PROTOTYPE`: The root of an AST, generated by `PARSER`.<br>
+ <span class="c2"><span class="c1">375</span></span><br>
+ <span class="c2"><span class="c1">376</span></span> - `TYPE` hierarchy: the type information used for code life and execution<br>
+ <span class="c2"><span class="c1">377</span></span> passes. This hierarchy represents a bare type without customization<br>
+ <span class="c2"><span class="c1">378</span></span> (`Strict`, `Expanded`, ...)<br>
+ <span class="c2"><span class="c1">379</span></span><br>
+ <span class="c2"><span class="c1">380</span></span> - `TYPE_FULL`: type with its customization.<br>
+ <span class="c2"><span class="c1">381</span></span><br>
+ <span class="c2"><span class="c1">382</span></span> Tools<br>
+ <span class="c2"><span class="c1">383</span></span> -----<br>
+ <span class="c2"><span class="c1">384</span></span><br>
+ <span class="c2"><span class="c1">385</span></span> # `ALIAS_STR` #<br>
+ <span class="c2"><span class="c1">386</span></span><br>
+ <span class="c2"><span class="c1">387</span></span> `ALIAS_STR.get` serves to convert `STRING` to `STRING_CONSATNT`. The `STRING`s<br>
+ <span class="c2"><span class="c1">388</span></span> have to be compared using `==` while only `=` is necessary for<br>
+ <span class="c2"><span class="c1">389</span></span> `STRING_CONSTANT`s.<br>
+ <span class="c2"><span class="c1">390</span></span><br>
+ <span class="c2"><span class="c1">391</span></span> # `ALIAS_ARRAY` #<br>
+ <span class="c2"><span class="c1">392</span></span><br>
+ <span class="c2"><span class="c1">393</span></span> Storage pool for arrays, keep the memory from groing too much. This will give<br>
+ <span class="c2"><span class="c1">394</span></span> you an array with its capacity closest to what you need avoiding too much<br>
+ <span class="c2"><span class="c1">395</span></span> reallocation.<br>
+ <span class="c2"><span class="c1">396</span></span><br>
+ <span class="c2"><span class="c1">397</span></span> # `POSITION` #<br>
+ <span class="c2"><span class="c1">398</span></span><br>
+ <span class="c2"><span class="c1">399</span></span> Encodes in 32 bits any position in any file parsed now or ever. It contains a<br>
+ <span class="c2"><span class="c1">400</span></span> type id, a line number and a column number. 32 bits are a bit small but for the<br>
+ <span class="c2"><span class="c1">401</span></span> moment we hold it.<br>
+ <span class="c2"><span class="c1">402</span></span><br>
+ <span class="c2"><span class="c1">403</span></span> # `PARSER` #<br>
+ <span class="c2"><span class="c1">404</span></span><br>
+ <span class="c2"><span class="c1">405</span></span> The parser<br>
+ <span class="c2"><span class="c1">406</span></span><br>
+ <span class="c2"><span class="c1">407</span></span> # `COMMON` #<br>
+ <span class="c2"><span class="c1">408</span></span><br>
+ <span class="c2"><span class="c1">409</span></span> Common things for command lines. This is used by `LISAAC` and `SHORTER` to<br>
+ <span class="c2"><span class="c1">410</span></span> display help and compiler version.<br></span>
+</body>
+</html>
diff --git a/src/type/type.li b/src/type/type.li
index 11e5c32..74a492a 100644
--- a/src/type/type.li
+++ b/src/type/type.li
@@ -50,6 +50,7 @@ Section Private
Section Public
+ param_count:INTEGER;
+ // param count
- set_param n:INTEGER <-
(
@@ -57,12 +58,14 @@ Section Public
);
+ subtype_list:HASHED_SET(TYPE);
+ // inherited type ?
+ default:TYPE_FULL;
+ size:INTEGER;
- position:POSITION <- prototype.position;
+ // position in source code
- parameter_to_type p:ITM_TYPE_PARAMETER :TYPE_FULL <-
(
@@ -74,6 +77,7 @@ Section Public
//
+ last_pass_binding:INTEGER;
+ // depend pass count
- is_late_binding:BOOLEAN <- pass_count = last_pass_binding;
@@ -89,6 +93,7 @@ Section Public
+ itm_type:ITM_TYPE_SIMPLE;
+ prototype:PROTOTYPE;
+ // prototype associated
- type_c:STRING_CONSTANT <- prototype.type_c;
--
Lisaac compiler
More information about the Lisaac-commits
mailing list