Ah, I read too quickly, didn't notice/realize the "length(...)"
subexpression was the variable part.

If you don't have alloca, and you don't want to use assembler, and you
don't want the overhead of malloc/free, and you don't want to, or literally
can't, risk "demons flying out of your nose":

typedef char byte;
byte hack[HACK_SIZE];  // "hack" is meant to remind one of "stack"
byte * hack_ptr = hack+(HACK_SIZE-1);
void * hack_alloc(size_t num_bytes) {
  return hack_ptr -= num_bytes;
void * hack_dealloc(size_t num_bytes) {
  return hack_ptr += num_bytes;
// if you don't trust your compiler to inline one-liners (what?! get a new
compiler, and/or file a bug report, but if all else fails):
//#define hack_alloc(n) ((void *)hack_ptr -= n)
//#define hack_dealloc(n) ((void *)hack_ptr += n)
// you can call these "push" and "pop" or something similar instead.
// (if you get annoyed by the type casting, you can change to a byte *
interface instead of a void * interface, ofc.)
// Importantly though, dealloc isn't free; you have to track lengths
separately all the way from alloc to dealloc,
// which automation is a (very) small part of the overhead of malloc/free.



If you're feeling dirty, and you know exactly how your compiler allocates
call frames, sometimes you can capture the address of your last local var,
as in:

int sp;
#define salloc(n) (sp -= n)
#define sdealloc(n) (sp += n)

void my_proc(my_vec x) {
 int i,j,k;
 sp = &k;

But this will surely fail (thankfully at compile-time) for
emscripten/clang.  Also, it will likely fail (at runtime, resulting in
'random' code execution) if the compiler introduces temporaries, or you
call subroutines.

A similar trick is:
  void * get_sp_here(int bogus) { return &bogus; }
but, again, this relies on implementation-defined behavior, which will
again be rejected by emscripten/clang.

On Mon, May 12, 2014 at 10:03 AM, Joe Bogner <joebog...@gmail.com> wrote:

> On Mon, May 12, 2014 at 11:50 AM, Christophe Gragnic <
> christophegrag...@gmail.com> wrote:
>> I just set up a repository on github (Alex being OK) and reported my
>> issue here:
>> https://github.com/Grahack/minipicolisp/issues/1
> I think the main difference is your Makefile
> https://github.com/Grahack/minipicolisp/commit/15a72e16b097336c3a1d3b4092f3656509183308
> Instead of:
> clang $*.c
> I'm doing this:
> $(CC) -w -c $*.c
> The -w suppresses warnings
> and then linking with:
> c:/Progra~2/LLVM/bin/clang.exe -o picolisp $(picoFiles:.c=.o)

Reply via email to