git.gag.com Git - fw/sdcc/blob - doc/random-notes.txt

   1 Random notes
   2 ------------
   3 A random set of notes about sdcc and how it works.
   4
   5 Sandeep:
   6 --------
   7 The Register Allocation story.
   8
   9 Before I get into this there are a few important fields
  10 on the iCode & oprtand data structures that need to be
  11 addressed.
  12
  13 iCode.
  14 -----
  15         ->key  -  is an unique number assigned to this
  16                   iCode when this icode is allocated.
  17
  18         ->seq  - sequence number of the iCode given in
  19                  acesnding order of execution.
  20
  21 operand.
  22 -------
  23         ->key  - unique number for an operand when operand
  24                  is allocated.
  25
  26 OP_LIVEFROM(op) - sequence number of the iCode where it was
  27                   first defined. Computed in SDCClrange.c
  28
  29 OP_LIVETO(op)   - sequence number of the iCode where it is
  30                   last used. Computed in SDCClrange.c
  31
  32
  33
  34
  35 Sandeep:
  36 --------
  37 Adding memory maps for AVR, setup default map for
  38 local & global variables in port.h will be initialised
  39 by the _<port>_finaliseOptions() [good functions]..some
  40 kludges remain because of the "overlay" segment for 8051.
  41
  42 The memory segment stuff will have to be made more flexible.
  43 Currently there does not seem to be a 1-to-1 correspondence
  44 between storage class & memory map. (should there be??).
  45
  46 Also Added check for memory map in SDCCmem.c allocLocal
  47 and allocglobal for "eeprom" memory space (AVR).
  48
  49
  50
  51 Michael:
  52 --------
  53 Tracing parmBytes and function calls.
  54
  55 Bug:
  56 void printf(const char *format);
  57
  58 void puts(const char *s)
  59 {
  60         printf(s);
  61 }
  62
  63 Generates the pseudo-code:
  64           hl = s
  65           push hl
  66           call printf
  67           pop l (not hl - so parmBytes is too small)
  68
  69 parmBytes for a function call seems to be setup in geniCodeCall in
  70 SDCCicode.c.
  71
  72 geniCodeCall:
  73 * Takes care of calls with side effects (?)
  74 * Generates the icode to push the parameters (this also computes the
  75   resulting stack size)
  76 * Generates a CALL or PCALL depending on if its a function or pointer to.
  77 * Computes the result
  78 * Adds the code for the call to the chain.
  79
  80 My bug is probably in geniCodeParms - it's probably computing the
  81 size of pointers wrong.
  82
  83 geniCodeParms:
  84 * A 'parm' node causes this to be run on the tree branches.
  85 * It switches on the stack mode and sendto mode, and adds the
  86   instructions required to push or put.
  87 * A push adds the result of 'getSize' to the stack size.
  88
  89 So the bug is probably in getSize.  's' is not an aggregate, so the
  90 bug is in getSize().
  91
  92 It seems that IS_SPEC() is being set, deferencing *s so that it's size
  93 is sizeof(char) == 1.  It's either a SPECIFIER or a DECLARATOR - seems that
  94 were the wrong way around.  This is set in SDCCsymt.c, SDCCval.c, and the
  95 yacc file. SDCCsymt.c and SDCCval.c havnt really changed in 5 days - must
  96 be SDCC.y.  Nope, no changes.  diff against 5 days ago shows only intersting
  97 changes are in SDCCicode.  Same with -14 days.
  98
  99 Michael
 100 -------
 101 Next bug is global function parameters not being pushed correctly. i.e
 102
 103 unsigned int counter;
 104
 105 void print(void)
 106 {
 107         printf("Counter is %u\n", counter);
 108 }
 109 generates:
 110 _print::
 111         ld hl,#_counter
 112         push hl
 113         ld hl,#str_1
 114         push hl
 115         call printf
 116         fix, ret
 117
 118 which is more like:
 119         printf("Counter is %u\n", &counter);
 120
 121 First looking in SDCCicode.c for the stuff that generates function calls:
 122 Probably a bug in geniCodeParams.
 123 Nope, a bug in my stuff :)