Changes between Version 2 and Version 3 of Commentary/Compiler/Backends/PprC


Ignore:
Timestamp:
Apr 9, 2008 8:32:18 PM (6 years ago)
Author:
simonmar
Comment:

add information about prototypes

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Compiler/Backends/PprC

    v2 v3  
    2121This has several advantages: 
    2222   
    23   * `-fvia-C` is consistent with `-fasm` with respect to FFI declarations: 
    24      both bind to the ABI, not the API. 
     23 * `-fvia-C` is consistent with `-fasm` with respect to FFI declarations: 
     24   both bind to the ABI, not the API. 
    2525   
    26   * foreign calls can now be inlined freely across module boundaries, since 
    27     a header file is not required when compiling the call. 
     26 * foreign calls can now be inlined freely across module boundaries, since 
     27   a header file is not required when compiling the call. 
    2828   
    29   * bootstrapping via C will be more reliable, because this difference 
    30     in behavour between the two backends has been removed. 
     29 * bootstrapping via C will be more reliable, because this difference 
     30   in behavour between the two backends has been removed. 
    3131   
    32   There is one disadvantage: 
     32There is one disadvantage: 
    3333   
    34   * we get no checking by the C compiler that the FFI declaration 
    35     is correct. 
     34 * we get no checking by the C compiler that the FFI declaration 
     35   is correct. 
    3636   
    3737== Prototypes == 
    3838 
     39When a label is referenced by an expression, the compiler needs to 
     40know whether to declare the label first, and if so, at what type. 
     41 
     42 * all labels referenced as a result of an FFI declaration 
     43   are declared as `extern StgWord[]`, including funciton labels. 
     44   If the label is called, it is first cast to the correct 
     45   function type.  This is because the same label might be 
     46   referred to both as a function and an untyped data label in 
     47   the same module (e.g. Foreign.Marsal.Alloc refers to "free" 
     48   this way). 
     49 
     50 * all RTS symbols already have declarations (mostly with the correct 
     51   type) in [[GhcFile(includes/StgMiscClosures.h)]], so no declarations are generated. 
     52 
     53 * certain labels are known to have been defined earlier in the same file, 
     54   so a declaration can be omitted (e.g. SRT labels) 
     55 
     56 * certain math functions (`sin()`, `cos()` etc.) are already declared because 
     57   we #include math.h, so we don't emit declarations for these.  We need 
     58   to #include math.h because some of these fuctions have inline 
     59   definitions, and we get terrible code otherwise. 
     60 
     61When compiling the RTS cmm code, we have almost no information about 
     62labels referenced in the code.  The only information we have is 
     63whether the label is defined in the RTS or in another package: a label 
     64that is declared with an import statement in the .cmm file is assumed 
     65to be defined in another package (this is for dynamic linking, where 
     66we need to emit special code to reference these labels). 
     67 
     68For all other labels referenced by RTS .cmm code, we assume they are 
     69RTS labels, and hence already declared in [[GhcFile(includes/StgMiscClosures.h)]].  This is 
     70the only choice here: since we don't know the type of the label (info, 
     71entry etc.), we can't generate a correct declaration. 
     72