Changeset 2668


Ignore:
Timestamp:
Nov 21, 2012, 6:17:53 PM (6 years ago)
Author:
ksherdy
Message:

Refactored launch configurations. Clean up grammars.

Location:
proto/pablo
Files:
3 added
2 deleted
1 edited
2 copied

Legend:

Unmodified
Added
Removed
  • proto/pablo/ReadMe.txt

    r2658 r2668  
    1 Implementation Changes
     1PabloJ - Pablo language implementation.
    22
    3 1. Split CarryIntro visitor into two vistor passes.
    4    If, While, Body. Add Carry Calls.
     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'* } )?
    523           
    6            Pablo 'if'
    7                
    8        Parallel bit stream language construct --> Block-at-a-time implementation.
    9    
    10            if(C) { S* } --> if (C || any_carry(base,count)) { S* } else { enqueue_dequeue(base, count) }
     24-->
    1125           
    12            Pablo 'while'
     26if (bitblock::any(E | carryQ.any_carry(base,count)) { S* } else { carrrQ.enqueue_dequeue(base, count); }
    1327           
    14        while(C) { S* } --> if (C || any_carry(base, count))
    15                            {
    16                              S*
    17                              while(C) {
    18                                S*
    19                              }
    20                            }
    21                            else
    22                            {
    23                              enqueue_dequeue(base, count)
    24                            } 
    25                                    
    26        Pablo 'body'
     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);
    2752       
    28        (ii) Translate carry generating built-in operations.
     53Missing Features
    2954
    30 Todo List
    31 
    32 1. Support negative numbers.
    33 2. Fix indentation. Nested if's etc.   
    34 //3. simd::constant<1>(0) <-- if CarryQ ignore
     551. Support for negative constant integers (-1).
     56//2. Code indentation.   
     57//3. Pablo '1' --> simd::constant<1>(0)
    3558//4. Add assert compiler.
    3659//5. Add SIMD register dump.
    37 //6. if stream_function.carry_count > 0:
    38 //       node.body += [mkCallStmt('carryQ.CarryQ_Adjust', [ast.Num(stream_function.carry_count)])]
     60//6. carryQ.CarryQ_Adjust
     617. Map substitutions.
    3962
    40 Current Compiler Design Issues
     63PabloJ Design Issues
    4164 
    42 1. Replace all occurrences of X.getCPPCode() with a generic getCode call
     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
    4370   that is configurable based on the target back-end. e.g. C macro syntax
    4471   versus C++ template syntax etc.
     
    4673   Done.
    4774   
    48 2. Divide the compiler into phases to promote the decoupling of visitor passes.
    49    (a) Analysis phases - Gather information and populate symbol table information.
     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.
    5078   
    51    (b) AST augmenting / altering phases that alter the PABLO AST in a
    52        target back-end independent fashion.
     79   (b) AST modification
    5380   
    54    (c) Code generation phases. Dependent on the target language and hardware.
    55 
    56    (d) Name Visitors SomeNameVisitor, InnerSomeNameVisitor; and Name SomeNameXFormer, InnerSomeNameXFormer.
     81   (c) Target language instruction generation (unparsing).
    5782
    5883   Work in progress.
    5984   
    60 3. Visitor dependency. Tree XFormation, e.g. carry counter depends on
    61    'Advance(x)' function name and argument count.
    62    
     853. AST Visitor naming conventions.
     86
     87   Term non-AST modifying visitors XVisitor and AST modifying visitors XXFormers.
    6388   Done.
    64    
    65 4. Boolean OR, Boolean AND. Pablo may require a boolean type as well as binary and boolean
    66    AND,OR operators.
    67 
    68    Options:
    69    
    70    Restricted compiler operator.
    71    Add to Pablo language, poor choice.
    72    Boolean type.
    73    String value produced for evaluation as a function name within 'if' tests.
    74 
    75    I believe the following the correct block-at-a-time implementation. This avoids the
    76    introduction of a Boolean type to the Pablo language.
    77 
    78    --> if((bitblock::any(C | CarryQ.CarryTest(base,count))
    79    
     89     
    8090   Done.
    8191
    82 5. Verify function call expressions versus function call Stmts. Go over code
    83    generation scheme.
     924. Verify function call expressions versus function call statements in C++ unparsing.
     93   Review the the current scheme.
    8494         
    8595   Pending.     
  • proto/pablo/input/test/visitors/Bitwise2IDISAXFormer/bitwise2IDISA.pablo

    r2658 r2668  
    1616        r = (x & y);                    // Actual
    1717
    18         r = simd_and(x, simd_not(y));   // Expected
    19         r = (x & ~ y);                                  // Actual
     18        r = simd_andc(x, y);    // Expected
     19        r = (x & ~ y);                  // Actual
     20
     21        r = simd_andc(y, x);    // Expected
     22        r = (~x & y);                   // Actual
    2023
    2124        r = simd_xor(x,y);              // Expected
  • proto/pablo/runConfigurations/pablo.launch

    r2657 r2668  
    33<stringAttribute key="bad_container_name" value="/prot/pablo/runConfigurations"/>
    44<listAttribute key="org.eclipse.debug.core.MAPPED_RESOURCE_PATHS">
    5 <listEntry value="/pablo/src/compiler/PabloCompiler.java"/>
     5<listEntry value="/pablo/src/pablo/applications/ApplicationGenerator.java"/>
    66</listAttribute>
    77<listAttribute key="org.eclipse.debug.core.MAPPED_RESOURCE_TYPES">
    88<listEntry value="1"/>
    99</listAttribute>
    10 <stringAttribute key="org.eclipse.jdt.launching.MAIN_TYPE" value="compiler.PabloCompiler"/>
     10<stringAttribute key="org.eclipse.jdt.launching.MAIN_TYPE" value="pablo.applications.ApplicationGenerator"/>
    1111<stringAttribute key="org.eclipse.jdt.launching.PROGRAM_ARGUMENTS" value="-i ${workspace_loc}/pablo/input/test/pablo/py2pablo/parabix2_pablo.pablo.exclude"/>
    1212<stringAttribute key="org.eclipse.jdt.launching.PROJECT_ATTR" value="pablo"/>
Note: See TracChangeset for help on using the changeset viewer.