source: proto/pablo/ReadMe.txt @ 2702

Last change on this file since 2702 was 2702, checked in by ksherdy, 6 years ago

General refactoring (variable names). Added final block XFormer. Move final block operations atEOF/inFile out of carry intro transformer to final block transformer.

File size: 4.6 KB
Line 
1PabloJ - Pablo language implementation.
2
3(1) Translates arbitrary length 2^k bit field width streams to an equivalent block-at-a-time target language implementation.
4(2) ...
5
6PabloJ Design Differences
7
81. Programmer defined stream function variable declaration. PabloJ does not gather local variables.
9
10PabloJ Implementation Differences
11
122. Split CarryIntro into separate passes:
13(i) Add carry macros to AST.
14
15Pablo 'if' - Note: The PabloJ translation of 'if' differs slightly from Pablo (Python).
16               
17E - Pablo Expression
18S - Pablo Statement     
19               
20Pablo --> C++/IDISA block-at-a-time target language implementation.
21   
22if ( E ) { S* } (else { S'* } )?
23           
24-->
25           
26if (bitblock::any(E | carryQ.any_carry(base,count)) { S* } else { carrrQ.enqueue_dequeue(base, count); }
27           
28Pablo 'while'
29           
30while ( E ) { S* }
31
32-->
33
34if (bitblock::any(E | carryQ.any_carry(base, count))
35{
36  S*
37  while(E)
38  {
39    S*
40  }
41}
42else
43{
44  carryQ.enqueue_dequeue(base, count);
45
46
47Pablo 'body'
48
49-->
50
51  body += carryQ.carryAdjust(base, count);
52       
53Missing Features
54
551. Support for negative constant integers (-1).
56//2. Code indentation.   
57//3. Pablo '1' --> simd::constant<1>(0)
58//4. Add assert compiler.
59//5. Add SIMD register dump.
60//6. carryQ.CarryQ_Adjust
617. Map substitutions.
62
63PabloJ Design Issues
64 
651. Front-end / Back-end decoupling. Support for multiple target languages (C/C++).
66
67   TODO
68   
69   Replace all occurrences of X.getCPPCode() with a generic getCode call
70   that is configurable based on the target back-end. e.g. C macro syntax
71   versus C++ template syntax etc.
72 
73   Done.
74   
752. Logical division of the compiler into phases to promote the decoupling of visitor passes.
76
77   (a) Analysis - Gather information and populate symbol table information.
78   
79   (b) AST modification
80   
81   (c) Target language instruction generation (unparsing).
82
83   Work in progress.
84   
853. AST Visitor naming conventions.
86
87   Term non-AST modifying visitors XVisitor and AST modifying visitors XXFormers.
88   Done.
89     
90   Done.
91
924. Verify function call expressions versus function call statements in C++ unparsing.
93   Review the the current scheme.
94         
95   Pending.     
96   
975. Decision to analyze a list of AST nodes in the semantic analyzer.
98   Perhaps this should be skipped we should simply push processing up to the program node level.
99   This may reduce future code changes.
100   Plan to add a graph type to the compiler to organize the stream program generation.
101
1026. Decision to call AST transformer a 'semantic analyzer'.
103
1047. Add a symbol table and type checking to rid the compiler of the upper case naming
105   convention for stream function and stream structures.
106   
1078. Pass around a configuration object or have setters on the semantic analyzer object.     
108
1099. ApplicationConfigurationFactory generates an ApplicationConfiguration object. Not sure if this oject
110   should be a singleton.
111   
11210. Semantic analyzer. Add Scatter logging.   
113
11411. Clone AST or not.
115
11611. X2Lang design decision. enum/assert etc...
117
11812. do_block()/do_final_block() code generation implementation.
119
120        We attach nodes to the Pablo AST to produce do_block() versus do_final_block() code.
121
122        Case do_block()
123
124->
125
126
127        Case do_final_block()
128
129->
130       
131        Implementation options:
132       
133        (a) Parse source file twice to produce two separate AST.
134        (b) Clone complete AST. Apply AST transformation passes to both ASTs.
135        (c) Add both body and final block bodies to a single AST.
136       
137        An additional decision remains as to which point in Pablo AST transformation we clone ASTs.
138
13913. Carry mode (ci/co) and do_block/do_final_block are independent concepts.
140
141        In the current approach we restrict the carry mode dependent transformation of the AST to
142        the transformation to:
143       
144        Pablo while
145       
146->     
147       
148        Prior carry operations considered carry mode in the selection of carry dependent operations.
149        For example, final block carry producing operations are not 'strictly' required to write
150        carry out values.
151
15214. 3-Addr Form (SSA) AST permits the applications of simplification rules (local optimization)
153        of the AST.     
154
155Additional Notes
156
157Ci|Co
158-----
159F | F
160F | T
161T | F
162T | T
163       
164+ Carry Modes   
165
166Pablo language control structures.     
167       
168Ci/Co (Carry In / Carry Out Mode)
169
170- While statements (1st iteration)
171- If statements
172
173Ci (Carry In Only Mode)
174
175- While statements iteration i>1
176
177Co (Carry Out Only Mode)
178
179...
180
181Pablo builtins
182
183ScanToFirst - Special consideration at initial block as well as atEOF, i.e. set carry bit at SOF, inFile(), atEOF()?
184SpanUpTo        - Special consideration atEOF, i.e. check to ensure scan terminates at a valid position
185Advance
186AdvanceN
187
188+ Block Types
189
190Initial block(ScanToFirst)
191Intermediate block (Non-initial and Non-final block)
192Final block
193Initial/Final block
194
Note: See TracBrowser for help on using the repository browser.