From: NoEmail@nospicedham.trraxvfeqa.prg   
      
   On Fri, 11 May 2018 20:29:46 -0700 (PDT)   
   luserdroog  wrote:   
      
   > I've settled on using si for now. bp seems tempting for this, but   
   > you always have to have a displacement even if it's zero because   
   > mod=0 r/m=6 does something else. So using si I have   
   >   
   > mov si, sp   
   > mov ax, [si]   ; smaller encoding   
   >   
   > and   
   >   
   > mov si, sp   
   > mov ax, [si+2]   
   >   
   > For giggles, here's my draft so far. In a form which should   
   > be convenient to plug into my emulator.   
   >   
      
   If you're loading SI, you can use LODSW.  It will index SI for you.   
   Use CLD or STD to set the direction, increment or decrement, for   
   indexing.   
      
   > $ cat forth.h   
   > #define NEXT HEX3(ad,ff,e8)   
   > #define CHAR(x) *#x   
   > #define CHAR2(x,y) CHAR(x),CHAR(y)   
   > #define CHAR3(x,y,z) CHAR2(x,y),CHAR(z)   
   > #define CHAR4(w,x,y,z) CHAR2(w,x),CHAR2(y,z)   
   > #define CHAR5(w,x,y,z,a) CHAR4(w,x,y,z),CHAR(a)   
   > #define HEX(y) 0x##y   
   > #define HEX2(x,y) HEX(x),HEX(y)   
   > #define HEX3(x,y,z) HEX2(x,y),HEX(z)   
   > #define HEX4(w,x,y,z) HEX2(w,x),HEX2(y,z)   
   > #define HEX5(w,x,y,z,a) HEX4(w,x,y,z),HEX(a)   
   >   
   > static inline int   
   > forth(char *mem){   
   >   char image[] = {   
   >     0, 4, CHAR4(d,r,o,p), HEX(58), NEXT,   
   >     0, 4, CHAR4(s,w,a,p), HEX4(58,5b,50,53), NEXT,   
   >     0, 3, CHAR3(d,u,p),0, HEX5(8b,ec,8b,5,50), NEXT,   
   >     0, 4. CHAR4(o,v,e,r), HEX6(8b,ec,8b,45,2,50), NEXT,   
   >     0, 3, CHAR3(r,o,t),0, HEX6(58,5b,59,53,50,51), NEXT,   
   >     0, 4, CHAR4(-,r,o,t), HEX6(58,5b,59,50,51,53), NEXT,   
   >     0, 5, CHAR5(2,d,r,o,p),0, HEX2(58,59), NEXT,   
   >     0, 4, CHAR4(2,d,u,p), HEX4(8b,ec,8b,5),HEX5(8b,5d,2,53,50), NEXT,   
   >     0, 5, CHAR5(2,s,w,a,p),0, HEX4(58,5b,59,5a),HEX4(53,50,52,51),   
   > NEXT, 0, 4, CHAR4(?,d,u,p),   
   > HEX4(8b,ec,8b,5),HEX2(85,c0),HEX3(74,1,58), NEXT, 0, 2, CHAR2(1,+),   
   > HEX4(8b,ec,ff,5), NEXT, 0, 2, CHAR2(1,-), HEX4(8b,ec,ff,d), NEXT,   
   >     0, 1, CHAR(+),0, HEX5(58,8b,ec,1,5), NEXT,   
   >     0, 1, CHAR(-),0, HEX5(58,8b,ec,29,5), NEXT,   
   >     0, 1, CHAR(*),0, HEX5(58,5b,f7,eb,50), NEXT,   
   >   };   
   >   memcpy(mem, image, sizeof image);   
   > }   
   >   
   >   
      
   It works, but ouch.   
      
   Word alignment?   
      
   Is there some reason why putc() or putchar() i.e., send characters   
   directly to an open tmpfile() file, wouldn't work in your macros?   
      
   > Need to stitch up the link fields somehow.   
      
   Of course, &image[XX], provides the address: image+XX.  However, you   
   only have a byte to encode a length to the next primitive.  You could   
   subtract two addresses.  The problem is that any time you insert or   
   delete bytes into any Forth word within image[], /all/ of the XX   
   indexes from there onwards to the end of the dictionary, become   
   incorrect and must be manually adjusted, since their values have been   
   hard coded.  BTDT.   
      
   Now, if you called putc() or putchar() in your macros to write the   
   bytes out to a file, then you could create a wrapper routine for putc()   
   or putchar(), say i_putc(), which also increments a counter variable   
   every time you output a character to a file.  This variable would give   
   you the current index position within image[].  Any time the char was   
   '\0', you'd save the counter to subtract to later subtract from the   
   current counter to obtain the LFA offset.  Of course, that would mean   
   that you'd need to use something other than '\0' for word padding the   
   name field, e.g., perhaps a space.   
      
      
   Rod Pemberton   
   --   
   I believe in the right to life.  That's why I oppose gun control.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)