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 21:29]
soc:2009:lynusvaz:journal:week6 [2009/07/05 21:45] (current)
Line 42: Line 42:
   * [[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=7815aecdab93649a3e80efa50ccf4787aa02f0b7|Using lists]]
   * [[http://​git.etherboot.org/?​p=people/​lynusvaz/​gpxe.git;​a=commit;​h=dfd9803e73cc9d4b332c741ef1cc59c9fd6c0a19|Remove the prog_ctr variable]]   * [[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)