source: proto/pabloj/trunk/docs/notes @ 2834

Last change on this file since 2834 was 2834, checked in by ksherdy, 7 years ago

Migrated pablo to pabloj/trunk.

File size: 7.5 KB
Line 
1Pablo vs. PabloJ Implementation Differences
2
3(1) Explicit local variable declarations with explicit types.
4
5e.g. bitblock s; s = simd::constant<1>(0);
6
7(2) Current PabloB grammar does not support boolean OR.
8
9Work around. Added PabloJCarryTest runtime check that returns a type BitBlock.
10Wrapped 'if' / 'while' conditions within bitblock::any() IDISA call.
11
12(3) TODO - Avoid carry object creation in Kernel w/o carries.
13
14(4) BitBlock EOF_mask --> const BitBlock mask
15
16(5) 
17
18PabloB - PabloB language implementation / design
19
20(1) 'static' initialization section vs. 'kernel' constructor
21
22(2) integer types uint8, uint16, uint32, uint64, uint128, uint256
23  - if integer types are restricted 'sections' of stream then no apparent need exists for signed integers
24
25C++ Code Generation Strategy
26
27(1) sythetic variable, scope, identifiers, tree compression, etc...
28
29PabloJ - Pablo language implementation.
30
31(1) Translates arbitrary length 2^k bit field width streams to an equivalent block-at-a-time target language implementation.
32(2) ...
33
34PabloJ Design Differences
35
361. Programmer defined stream function variable declaration. PabloJ does not gather local variables.
37
38PabloJ Implementation Differences
39
402. Split CarryIntro into separate passes:
41(i) Add carry macros to AST.
42
43Pablo 'if' - Note: The PabloJ translation of 'if' differs slightly from Pablo (Python).
44               
45E - Pablo Expression
46S - Pablo Statement     
47               
48Pablo --> C++/IDISA block-at-a-time target language implementation.
49   
50if ( E ) { S* } (else { S'* } )?
51           
52-->
53           
54if (bitblock::any(E | carryQ.any_carry(base,count)) { S* } else { carrrQ.enqueue_dequeue(base, count); }
55           
56Pablo 'while'
57           
58while ( E ) { S* }
59
60-->
61
62if (bitblock::any(E | carryQ.any_carry(base, count))
63{
64  S*
65  while(E)
66  {
67    S*
68  }
69}
70else
71{
72  carryQ.enqueue_dequeue(base, count);
73
74
75Pablo 'body'
76
77-->
78
79  body += carryQ.carryAdjust(base, count);
80       
81Missing Features
82
831. Support for negative constant integers (-1).
84//2. Code indentation.   
85//3. Pablo '1' --> simd::constant<1>(0)
86//4. Add assert compiler.
87//5. Add SIMD register dump.
88//6. carryQ.CarryQ_Adjust
897. Map substitutions.
90
91PabloJ Design Issues
92 
931. Front-end / Back-end decoupling. Support for multiple target languages (C/C++).
94
95   TODO
96   
97   Replace all occurrences of X.getCPPCode() with a generic getCode call
98   that is configurable based on the target back-end. e.g. C macro syntax
99   versus C++ template syntax etc.
100 
101   Done.
102   
1032. Logical division of the compiler into phases to promote the decoupling of visitor passes.
104
105   (a) Analysis - Gather information and populate symbol table information.
106   
107   (b) AST modification
108   
109   (c) Target language instruction generation (unparsing).
110
111   Work in progress.
112   
1133. AST Visitor naming conventions.
114
115   Term non-AST modifying visitors XVisitor and AST modifying visitors XXFormers.
116   Done.
117     
118   Done.
119
1204. Verify function call expressions versus function call statements in C++ unparsing.
121   Review the the current scheme.
122         
123   Pending.     
124   
1255. Decision to analyze a list of AST nodes in the semantic analyzer.
126   Perhaps this should be skipped we should simply push processing up to the program node level.
127   This may reduce future code changes.
128   Plan to add a graph type to the compiler to organize the stream program generation.
129
1306. Decision to call AST transformer a 'semantic analyzer'.
131
1327. Add a symbol table and type checking to rid the compiler of the upper case naming
133   convention for stream function and stream structures.
134   
1358. Pass around a configuration object or have setters on the semantic analyzer object.     
136
1379. ApplicationConfigurationFactory generates an ApplicationConfiguration object. Not sure if this oject
138   should be a singleton.
139   
14010. Semantic analyzer. Add Scatter logging.   
141
14211. Clone AST or not. Clone.
143
14411. X2Lang design decision. enum/assert etc...
145
14612. do_block()/do_final_block() code generation implementation.
147
148        i.e. How do we represent/output both do_block and do_final_block function/code?
149
150        We attach nodes to the Pablo AST to produce do_block() versus do_final_block() code.
151
152        Case do_block()
153
154->
155
156        Case do_final_block()
157
158->
159       
160        Implementation options:
161       
162        (a) Parse source file twice to produce two separate AST.
163        (b) Clone complete AST. Apply AST transformation passes to both ASTs.
164        (c) Add both body and final block bodies to a single AST. We accomplish this through
165            the addition/introduce of both PabloS and PabloB grammars and translate
166            from PabloS to PabloB.
167       
168        An additional decision remains as to which point in Pablo AST transformation we clone ASTs.
169
170        Design choice taken (c): Translate from PabloS to PabloB.
171
17213. Carry mode (ci/co) and do_block/do_final_block are independent concepts.
173
174        In the current approach we restrict the carry mode dependent transformation of the AST to
175        the transformation to:
176       
177        Pablo while
178       
179->     
180       
181        Prior carry operations considered carry mode in the selection of carry dependent operations.
182        For example, final block carry producing operations are not 'strictly' required to write
183        carry out values.
184
18514. 3-Addr Form (SSA) AST permits the applications of simplification rules (local optimization)
186        of the AST.     
187
188Additional Notes
189
190Ci|Co
191-----
192F | F
193F | T
194T | F
195T | T
196       
197+ Carry Modes   
198
199Pablo language control structures.     
200
201Neither
202
203Ci (Carry In Only Mode)
204
205- While statements iteration i>1
206
207Co (Carry Out Only Mode)
208
209Ci/Co (Carry In / Carry Out Mode)
210
211- While statements (1st iteration)
212- If statements
213
214+ Potential Block Types
215
216Initial block(ScanToFirst)
217Intermediate block (Non-initial and Non-final block)
218Final block
219Initial/Final block
220
22115. Apply &~ EOF_mask to all pablo builtin operations.
222
223+ Final Block EOF_mask
224
225Builtins
226
227AdvanceThenScanThru(M,S)        --> AdvanceThenScanThru(M, (S &~ EOF_mask))
228AdvanceThenScanTo(M,S)          --> AdvanceThenScanThru(M,~(S &~ EOF_mask))
229
230inFile(E) --> S & EOF_mask  --> assert_0(inFile(E))
231
232i.e. look at only bits within the file extent
233
234i.e. tests only bits within the file the extent and then test none of this set of bits is marked
235
236atEOF(E)  --> S &~ EOF_mask --> assert_0(atEOF(E))
237
238i.e. look at only bits beyond the EOF
239 
240i.e. tests no bit beyond the file extents is marked
241
242Control Structures
243
244while (E) { S }
245
246-->
247
248if(bitblock::any( (E | carry_test(lower,count) &~ EOF_mask ) )
249{
250        S
251       
252        while (bitblock::any(simd_and(E, EOF_mask))
253        {
254                S
255        }
256}
257
258if (E) { S }
259
260-->
261
262if(bitblock::any( (E | carry_test(lower,count) &~ EOF_mask ) )
263{
264        S
265}
266
26716. PabloB grammar design issue (together with Carry InfoSet design)
268
269How do we add stream function level declaration / initialization code to the output?
270
271Options:
272
273(a) Add explicit carry info set information to the PabloB function definition representation.
274
275    No, this would burden the programmer at the PabloB level.
276    The idea is the we remove carry counting ... from the developer
277    but still we need carry count / advn carry count information
278    for code output.
279   
280(b) Hold carry info set information in a symbol table external
281        to both PabloB. Query this data structure during code generation.
282   
283(a) and (b) are similar in that both options remove explicit carry counting from the programmer.
284
285We currently translate PabloS to PabloB and PabloS code is used to populate the information
286contained in the symbol table used by PabloB.
287
288We could populate similar symbol table information based on PabloB code alone.
289
290More investigation is required here.
291
29217. Limitations of a macro driven carry handling approach.
293
294Fill in this section ...
295
29618. PabloB needs both bitwise OR as well as boolean OR.
297
29819. Translate to Dotty for AST diagrams.
299   
300
Note: See TracBrowser for help on using the repository browser.