Hi Will,

thanks for you long explanation!


On Fri, May 9, 2014 at 7:59 PM, Rick Lyman <lyman.r...@gmail.com> wrote:
> flow.c:60:37: error: fields must have a constant size: 'variable length
> array in
>
>       structure' extension will never be supported
>          struct {any sym; any val;} bnd[length(x)];


On Sun, May 11, 2014 at 12:19:46PM -0700, William Cushing wrote:
> The normal thing to do, when encountering this problem, is to replace the
> variable length arrays with pointers.  As in "char foo[]" -> "char * foo".

Correct.


> For a LISP VM, for specifically the case of the root type of the VM, it
> might make more sense (than making "any" a typedef for "void *") to make
> "any" a typedef for a tagged union along the lines of:
> 
> typedef union {
>   char c;
>   short s;
>   ...
> } all_builtin_types_type;
> 
> typedef struct {
>   tag_type tag;
>   all_builtin_types_type value;
> } any;


No. "any" is in fact a fixed-sized structure:

   typedef struct cell {            // PicoLisp primary data type
      struct cell *car;
      struct cell *cdr;
   } cell, *any;

This is not the problem.

The problem is that all data sizes (lengths of lists, number of
arguments to functions, sizes of various structures) are dynamic in
PicoLisp, and determined at runtime.


Considering the above case

   struct {any sym; any val;} bnd[length(x)];

which, btw, could also be typedef'd as

   typedef struct myStruct {
      any sym;
      any val;
   } myStruct;

and then written as

   myStruct bnd[length(x)];


So for a compiler not supporting variable length arrays and structures,
the above statement must be rewritten as

   myStruct *bnd;

   ...

   bnd = malloc(length(x) * sizeof(myStruct));


The problem with this is that is horribly inefficient. The dynamic version

   myStruct bnd[length(x)];

simply decrements the stack pointer by "length(x) * sizeof(myStruct)"
(which is a single machine instruction!), while the malloc() call
involves the whole memory management machinery.

And then, don't forget the free() call!


If the compiler supports alloca(), then it could be used instead of
malloc(), with similar efficiency. But I doubt it will be available,
because it requires the same runtime behavior.

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to