This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
soc:2009:lynusvaz:journal:week6 [2009/07/02 01:34]
soc:2009:lynusvaz:journal:week6 [2009/07/05 21:45] (current)
Line 30: Line 30:
   * [[http://​git.etherboot.org/?​p=people/​lynusvaz/​gpxe.git;​a=commit;​h=126682ab0c39427c75dc4770d74dc15a987a7932|Bugs fixed]]   * [[http://​git.etherboot.org/?​p=people/​lynusvaz/​gpxe.git;​a=commit;​h=126682ab0c39427c75dc4770d74dc15a987a7932|Bugs fixed]]
   * [[http://​git.etherboot.org/?​p=people/​lynusvaz/​gpxe.git;​a=commit;​h=e3374c796add6926718bbe2a67fe557e4a89cb5f|Remove size field from struct generic_stack]]   * [[http://​git.etherboot.org/?​p=people/​lynusvaz/​gpxe.git;​a=commit;​h=e3374c796add6926718bbe2a67fe557e4a89cb5f|Remove size field from struct generic_stack]]
 +July 2: Continued with yesterday'​s idea, and decided to see if using macros to inline the code would lead to some savings. The obvious code, allocating memory on the heap, did not offer any size changes. However, using arrays led to a decrease of around 0.5KB. But, doing so leads to a limit on features that use the stack: nesting of branches and loops, the number of arguments in a command, and the number of lines in a script. The first two could be solved by setting the limit high enough, but the last may be a problem. So, since the framework for lists is already present in <​gpxe/​lists.h>,​ I decided to store the commands using a list:
 +  struct command_entry {
 +      struct list_head neighbours;
 +      char line[1];
 +  };
 +The command_entry is allocated as malloc(sizeof(struct command_entry) + strlen(command)). This required some modification to the program counter. The loop information stored on the loop stack now stores a pointer to a command_entry struct stored in the heap. The prog_ctr variable is also replaced by a cur_command pointer, which points to the currently-executing command.
 +Today'​s commits:
 +  * [[http://​git.etherboot.org/?​p=people/​lynusvaz/​gpxe.git;​a=commit;​h=a0ee6ba8b094e49f62d40d473d860806a870e0c4|Macros on dynamically-allocated arrays]]
 +  * [[http://​git.etherboot.org/?​p=people/​lynusvaz/​gpxe.git;​a=commit;​h=ecc1283ac0266f2bd4a033a23c017697d4f1c8d0|Macros on static arrays]]
 +  * [[http://​git.etherboot.org/?​p=people/​lynusvaz/​gpxe.git;​a=commit;​h=7815aecdab93649a3e80efa50ccf4787aa02f0b7|Using lists]]
 +  * [[http://​git.etherboot.org/?​p=people/​lynusvaz/​gpxe.git;​a=commit;​h=dfd9803e73cc9d4b332c741ef1cc59c9fd6c0a19|Remove the prog_ctr variable]]
 +July 3: While working on quoting, I had missed out incomplete lines, for example:
 +  gPXE>​echo "Hello
 +  >​World"​
 +  gPXE>​echo Hello \
 +  >World
 +So I worked on this today. The idea is that I have a global variable that is set once the line is found to be incomplete. In the system() function, execv() is called with only complete lines, and the space used for the command is freed. Else, the command is kept stored in a static variable, and on the next call to system(), the new command is appended to the old one. The entire string is then parsed as usual.
 +  * [[http://​git.etherboot.org/?​p=people/​lynusvaz/​gpxe.git;​a=commit;​h=5bb4f424aaca9ede019a6981fae5fc09d5a4f096| Detect incomplete lines]]
 +July 4: Fixed a few memory leaks in arith.c, when incomplete arithmetic expressions are parsed. Valgrind came in pretty helpful again. Today'​s commit (I only had time to commit it on Monday morning, though):
 +  * [[http://​git.etherboot.org/?​p=people/​lynusvaz/​gpxe.git;​a=commit;​h=de62931f4e71ffbd738498de032852db80d1f167|Fixed memory leaks in arith.c, when parsing incomplete expressions]]
 +July 5: Didn't have time to do anything today, so I thought I'd explain some of the ideas behind the stack implementations:​
 +  - Stacks using arrays on the heap: These are dynamic arrays that grow and shrink as elements are pushed and popped. Implemented in a ''​struct generic_stack'',​ with fields ''​void *ptr''​ and ''​int tos''​.
 +Code is in the [[http://​git.etherboot.org/?​p=people/​lynusvaz/​gpxe.git;​a=shortlog;​h=refs/​heads/​expt|expt]] branch:
 +  * [[http://​git.etherboot.org/?​p=people/​lynusvaz/​gpxe.git;​a=commit;​h=e3374c796add6926718bbe2a67fe557e4a89cb5f|Using push and pop functions]]
 +  * [[http://​git.etherboot.org/?​p=people/​lynusvaz/​gpxe.git;​a=commit;​h=a0ee6ba8b094e49f62d40d473d860806a870e0c4|Using push and pop macros]]
 +There seems to be no code size advantage of either functions or macros over the other.
 +  - Stacks using static arrays: These are merely macros to initialise a static array and its counter, and to push and pop elements on and off the stack.
 +  INIT_STACK ( stack, int 5 )
 +translates to:
 +  int stack[5];
 +  int stack_tos = -1;
 +This seems to provide a space saving of 0.5KB over the dynamic stack. The disadvantage here is that since the arrays are fixed-size, they will limit loop and branch nesting, the command-line arguments, as well as the number of lines in a script. The first two may be fixed by setting a high limit, but the last may be a problem. Hence, the lines are now stored using a list_head structure, defined in <​gpxe/​list.h>​.
 +Code is in the [[http://​git.etherboot.org/?​p=people/​lynusvaz/​gpxe.git;​a=shortlog;​h=refs/​heads/​arrays|arrays]] branch:
 +  * [[http://​git.etherboot.org/?​p=people/​lynusvaz/​gpxe.git;​a=commit;​h=dfd9803e73cc9d4b332c741ef1cc59c9fd6c0a19|This is the last commit]]

QR Code
QR Code soc:2009:lynusvaz:journal:week6 (generated for current page)