www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - run-time stack-based allocation

reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
I'm working on dynamic memory layout manager. Simply put, it will
allow one to create and use struct types at run-time.
Normally, you create a struct at compile-time type by specifying an
ordered list of fields, each with its own type (basically a size) and
name.
You then access those fields by calling a compile-time evaluated dot
operator, which computes the address of the specified field given the
address of the struct.
What I'm trying to make is precisely that, except at run-time.

My question is: what is the best way of allocating such a structure on
the stack? It will, of course, have a dynamically known size.

-- 
Bye,
Gor Gyolchanyan.
May 07 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 07-05-2012 13:58, Gor Gyolchanyan wrote:

 I'm working on dynamic memory layout manager. Simply put, it will
 allow one to create and use struct types at run-time.
 Normally, you create a struct at compile-time type by specifying an
 ordered list of fields, each with its own type (basically a size) and
 name.
 You then access those fields by calling a compile-time evaluated dot
 operator, which computes the address of the specified field given the
 address of the struct.
 What I'm trying to make is precisely that, except at run-time.

 My question is: what is the best way of allocating such a structure on
 the stack? It will, of course, have a dynamically known size.


alloca?

-- 
- Alex
May 07 2012
parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
I can't use alloca, because the stack-based allocation will be done in
the constructor and alloca will free the memory as soon as the
constructor exists.

On Mon, May 7, 2012 at 4:01 PM, Alex R=C3=B8nne Petersen <xtzgzorex gmail.c=
om> wrote:

 On 07-05-2012 13:58, Gor Gyolchanyan wrote:

 I'm working on dynamic memory layout manager. Simply put, it will
 allow one to create and use struct types at run-time.
 Normally, you create a struct at compile-time type by specifying an
 ordered list of fields, each with its own type (basically a size) and
 name.
 You then access those fields by calling a compile-time evaluated dot
 operator, which computes the address of the specified field given the
 address of the struct.
 What I'm trying to make is precisely that, except at run-time.

 My question is: what is the best way of allocating such a structure on
 the stack? It will, of course, have a dynamically known size.


 alloca?

 --
 - Alex




--=20
Bye,
Gor Gyolchanyan.
May 07 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 07-05-2012 14:37, Gor Gyolchanyan wrote:

 I can't use alloca, because the stack-based allocation will be done in
 the constructor and alloca will free the memory as soon as the
 constructor exists.

 On Mon, May 7, 2012 at 4:01 PM, Alex Rønne Petersen<xtzgzorex gmail.com> 
wrote:

 On 07-05-2012 13:58, Gor Gyolchanyan wrote:

 I'm working on dynamic memory layout manager. Simply put, it will
 allow one to create and use struct types at run-time.
 Normally, you create a struct at compile-time type by specifying an
 ordered list of fields, each with its own type (basically a size) and
 name.
 You then access those fields by calling a compile-time evaluated dot
 operator, which computes the address of the specified field given the
 address of the struct.
 What I'm trying to make is precisely that, except at run-time.

 My question is: what is the best way of allocating such a structure on
 the stack? It will, of course, have a dynamically known size.


 alloca?

 --
 - Alex




If that's the case, I don't know how you actually want this stack 
allocation to work. The only way I see that you could do it would be 
with dirty hacks making assumptions about the compiler, platform, 
calling convention, ...

-- 
- Alex
May 07 2012
parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Basically I want what alloca does, but instead of considering the
constructor's scope, I want it to hand to the constructor call's
enclosing scope.

On Mon, May 7, 2012 at 5:29 PM, Alex R=C3=B8nne Petersen <xtzgzorex gmail.c=
om> wrote:

 On 07-05-2012 14:37, Gor Gyolchanyan wrote:

 I can't use alloca, because the stack-based allocation will be done in
 the constructor and alloca will free the memory as soon as the
 constructor exists.

 On Mon, May 7, 2012 at 4:01 PM, Alex R=C3=B8nne Petersen<xtzgzorex gmail=




.com>

 =C2=A0wrote:

 On 07-05-2012 13:58, Gor Gyolchanyan wrote:


 I'm working on dynamic memory layout manager. Simply put, it will
 allow one to create and use struct types at run-time.
 Normally, you create a struct at compile-time type by specifying an
 ordered list of fields, each with its own type (basically a size) and
 name.
 You then access those fields by calling a compile-time evaluated dot
 operator, which computes the address of the specified field given the
 address of the struct.
 What I'm trying to make is precisely that, except at run-time.

 My question is: what is the best way of allocating such a structure on
 the stack? It will, of course, have a dynamically known size.


 alloca?

 --
 - Alex




 If that's the case, I don't know how you actually want this stack allocat=


ion

 to work. The only way I see that you could do it would be with dirty hack=


s

 making assumptions about the compiler, platform, calling convention, ...

 --
 - Alex




--=20
Bye,
Gor Gyolchanyan.
May 07 2012
parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Monday, 7 May 2012 at 13:36:02 UTC, Gor Gyolchanyan wrote:

 Basically I want what alloca does, but instead of considering 
 the constructor's scope, I want it to hand to the constructor 
 call's enclosing scope.


I think you'd need to modify the compiler for this, since alloca 
is 'magical'.
May 07 2012
next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
I'd decrease ESP to allocate my space, but the problem arises when I
try to determine when should I increase it back where it was. Any
suggestions on how to do this using asm?

On Mon, May 7, 2012 at 8:03 PM, Mehrdad <wfunction hotmail.com> wrote:

 On Monday, 7 May 2012 at 13:36:02 UTC, Gor Gyolchanyan wrote:

 Basically I want what alloca does, but instead of considering the
 constructor's scope, I want it to hand to the constructor call's enclosing
 scope.



 I think you'd need to modify the compiler for this, since alloca is
 'magical'.




-- 
Bye,
Gor Gyolchanyan.
May 07 2012
prev sibling next sibling parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Wasn't there an allocator mechanism under development for phobos? I
remember there was a StackAllocator, that can span for arbitrary
scopes. What's up with that?

On Mon, May 7, 2012 at 8:03 PM, Mehrdad <wfunction hotmail.com> wrote:

 On Monday, 7 May 2012 at 13:36:02 UTC, Gor Gyolchanyan wrote:

 Basically I want what alloca does, but instead of considering the
 constructor's scope, I want it to hand to the constructor call's enclosing
 scope.



 I think you'd need to modify the compiler for this, since alloca is
 'magical'.




-- 
Bye,
Gor Gyolchanyan.
May 07 2012
next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
No idea, sorry. :\

On Monday, 7 May 2012 at 16:08:42 UTC, Gor Gyolchanyan wrote:

 Wasn't there an allocator mechanism under development for 
 phobos? I
 remember there was a StackAllocator, that can span for arbitrary
 scopes. What's up with that?

 On Mon, May 7, 2012 at 8:03 PM, Mehrdad <wfunction hotmail.com> 
 wrote:

 On Monday, 7 May 2012 at 13:36:02 UTC, Gor Gyolchanyan wrote:

 Basically I want what alloca does, but instead of considering 
 the
 constructor's scope, I want it to hand to the constructor 
 call's enclosing
 scope.



 I think you'd need to modify the compiler for this, since 
 alloca is
 'magical'.
May 07 2012
prev sibling parent reply dsimcha <dsimcha yahoo.com> writes:
On 5/7/2012 12:08 PM, Gor Gyolchanyan wrote:

 Wasn't there an allocator mechanism under development for phobos? I
 remember there was a StackAllocator, that can span for arbitrary
 scopes. What's up with that?


I wrote one.  It's at https://github.com/dsimcha/TempAlloc .  It hasn't 
been accepted to Phobos, though, because of issues w.r.t. figuring out 
what a more general allocator interface should look like.
May 07 2012
parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Cool! Thanks! I'l definitely check it out! I hope it's DDOCed :-D

On Tue, May 8, 2012 at 5:29 AM, dsimcha <dsimcha yahoo.com> wrote:

 On 5/7/2012 12:08 PM, Gor Gyolchanyan wrote:

 Wasn't there an allocator mechanism under development for phobos? I
 remember there was a StackAllocator, that can span for arbitrary
 scopes. What's up with that?



 I wrote one. =C2=A0It's at https://github.com/dsimcha/TempAlloc . =C2=A0I=


t hasn't been

 accepted to Phobos, though, because of issues w.r.t. figuring out what a
 more general allocator interface should look like.




--=20
Bye,
Gor Gyolchanyan.
May 08 2012
parent reply "Tove" <tove fransson.se> writes:
On Tuesday, 8 May 2012 at 07:03:35 UTC, Gor Gyolchanyan wrote:

 Cool! Thanks! I'l definitely check it out! I hope it's DDOCed 
 :-D


I just invented an absolutely wicked way of using alloca() in the 
parent context... unfortunately frame_size is static but with 
some work, it's still an usable method since it's mutable!

struct Wicked
{
   static int frame_size = 0;

   auto Create(void* buf=alloca(frame_size))
   {
     for(byte i=0;i<frame_size;++i)
       (cast(byte*)buf)[i]=i;

     struct Frame
     {
       size_t size;
     }

     Frame* xxx = cast(Frame*)buf;
     xxx.size=frame_size;

     return xxx;
   }

    disable this();

   this(size_t size)
   {
     frame_size = size;
   }
}
May 09 2012
next sibling parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
I thought function default parameters need to be statically known...
isn't it the case?

On Thu, May 10, 2012 at 12:17 AM, Tove <tove fransson.se> wrote:

 On Tuesday, 8 May 2012 at 07:03:35 UTC, Gor Gyolchanyan wrote:

 Cool! Thanks! I'l definitely check it out! I hope it's DDOCed :-D


 I just invented an absolutely wicked way of using alloca() in the parent
 context... unfortunately frame_size is static but with some work, it's st=


ill

 an usable method since it's mutable!

 struct Wicked
 {
 =C2=A0static int frame_size =3D 0;

 =C2=A0auto Create(void* buf=3Dalloca(frame_size))
 =C2=A0{
 =C2=A0 =C2=A0for(byte i=3D0;i<frame_size;++i)
 =C2=A0 =C2=A0 =C2=A0(cast(byte*)buf)[i]=3Di;

 =C2=A0 =C2=A0struct Frame
 =C2=A0 =C2=A0{
 =C2=A0 =C2=A0 =C2=A0size_t size;
 =C2=A0 =C2=A0}

 =C2=A0 =C2=A0Frame* xxx =3D cast(Frame*)buf;
 =C2=A0 =C2=A0xxx.size=3Dframe_size;

 =C2=A0 =C2=A0return xxx;
 =C2=A0}

 =C2=A0 disable this();

 =C2=A0this(size_t size)
 =C2=A0{
 =C2=A0 =C2=A0frame_size =3D size;
 =C2=A0}
 }




--=20
Bye,
Gor Gyolchanyan.
May 09 2012
parent "David Nadlinger" <see klickverbot.at> writes:
On Wednesday, 9 May 2012 at 20:52:33 UTC, Gor Gyolchanyan wrote:

 I thought function default parameters need to be statically 
 known...
 isn't it the case?


Nope – AFAIK you can also do something like (Foo param = new 
Foo).

David
May 09 2012
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/9/12 3:17 PM, Tove wrote:

 On Tuesday, 8 May 2012 at 07:03:35 UTC, Gor Gyolchanyan wrote:

 Cool! Thanks! I'l definitely check it out! I hope it's DDOCed :-D


 I just invented an absolutely wicked way of using alloca() in the parent
 context...


Yah, me too. 
http://forum.dlang.org/thread/i1gnlo$18g0$1 digitalmars.com#post-i1gql2:241k6o:2
1:40digitalmars.com 
I found it by googling for my name and "dark" and "devious" :o).

Andrei
May 09 2012
next sibling parent "Tove" <tove fransson.se> writes:
On Thursday, 10 May 2012 at 03:03:22 UTC, Andrei Alexandrescu 
wrote:

 On 5/9/12 3:17 PM, Tove wrote:

 On Tuesday, 8 May 2012 at 07:03:35 UTC, Gor Gyolchanyan wrote:

 Cool! Thanks! I'l definitely check it out! I hope it's DDOCed 
 :-D


 I just invented an absolutely wicked way of using alloca() in 
 the parent
 context...


 Yah, me too. 
 http://forum.dlang.org/thread/i1gnlo$18g0$1 digitalmars.com#post-i1gql2:241k6o:2
1:40digitalmars.com 
 I found it by googling for my name and "dark" and "devious" :o).

 Andrei


Muharrr, way cool :D We seriously need a highly visible "blog:ish 
page" (which was suggested in another lost thread), listing some 
useful D gems... I have a feeling these forums are a treasure 
trove with forgotten snippets...
May 10 2012
prev sibling parent "David Piepgrass" <qwertie256 gmail.com> writes:
On Thursday, 10 May 2012 at 03:03:22 UTC, Andrei Alexandrescu 
wrote:

 On 5/9/12 3:17 PM, Tove wrote:

 On Tuesday, 8 May 2012 at 07:03:35 UTC, Gor Gyolchanyan wrote:

 Cool! Thanks! I'l definitely check it out! I hope it's DDOCed 
 :-D


 I just invented an absolutely wicked way of using alloca() in 
 the parent
 context...

     auto Create(void* buf=alloca(frame_size))


 Yah, me too. 
 http://forum.dlang.org/thread/i1gnlo$18g0$1 digitalmars.com#post-i1gql2:241k6o:2
1:40digitalmars.com 
 I found it by googling for my name and "dark" and "devious" :o).


That is so awesome that it can't possibly be legal by the spec!

This "runtime struct" sounds really cool too. Pinch me, I must be 
dreaming :D
Jul 09 2012
prev sibling parent reply "Arne" <arne linux.nu> writes:
On Monday, 7 May 2012 at 16:03:15 UTC, Mehrdad wrote:

 On Monday, 7 May 2012 at 13:36:02 UTC, Gor Gyolchanyan wrote:

 Basically I want what alloca does, but instead of considering 
 the constructor's scope, I want it to hand to the constructor 
 call's enclosing scope.


 I think you'd need to modify the compiler for this, since 
 alloca is 'magical'.


wouldn't mixin's be a solution, one can inject an alloca to the 
current scope, and then call the constructor...

import std.stdio;
import std.c.stdlib;
import std.random;

mixin template Init(alias var, alias size)
{
   void* buf = alloca(size);

   bool foo_init()
   {
     var = (cast(typeof(var))buf);

     var[0]=0;
     var[1]=1;
     var[2]=2;

     return true;
   }

   auto foo_dummy_statement = foo_init();
}

void main()
{
   int my_size = uniform(12, 24);
   int* my_var = void; mixin Init!(my_var, my_size);

   writeln(my_var[0..3]);
}
May 07 2012
next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
That won't do. This is way too ugly, considering, that it needs to be
heavily used in user code. I'm thinking an inline ASM solution, but
can't figure out when to deallocate.

On Mon, May 7, 2012 at 8:52 PM, Arne <arne linux.nu> wrote:

 On Monday, 7 May 2012 at 16:03:15 UTC, Mehrdad wrote:

 On Monday, 7 May 2012 at 13:36:02 UTC, Gor Gyolchanyan wrote:

 Basically I want what alloca does, but instead of considering the
 constructor's scope, I want it to hand to the constructor call's enclos=






ing

 scope.



 I think you'd need to modify the compiler for this, since alloca is
 'magical'.



 wouldn't mixin's be a solution, one can inject an alloca to the current
 scope, and then call the constructor...

 import std.stdio;
 import std.c.stdlib;
 import std.random;

 mixin template Init(alias var, alias size)
 {
 =C2=A0void* buf =3D alloca(size);

 =C2=A0bool foo_init()
 =C2=A0{
 =C2=A0 =C2=A0var =3D (cast(typeof(var))buf);

 =C2=A0 =C2=A0var[0]=3D0;
 =C2=A0 =C2=A0var[1]=3D1;
 =C2=A0 =C2=A0var[2]=3D2;

 =C2=A0 =C2=A0return true;
 =C2=A0}

 =C2=A0auto foo_dummy_statement =3D foo_init();
 }

 void main()
 {
 =C2=A0int my_size =3D uniform(12, 24);
 =C2=A0int* my_var =3D void; mixin Init!(my_var, my_size);

 =C2=A0writeln(my_var[0..3]);
 }




--=20
Bye,
Gor Gyolchanyan.
May 07 2012
prev sibling parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Monday, 7 May 2012 at 16:52:18 UTC, Arne wrote:

 I think you'd need to modify the compiler for this, since 
 alloca is 'magical'.


 wouldn't mixin's be a solution, one can inject an alloca to the 
 current scope, and then call the constructor...


Yeah, but mixins are so hacky.
They're like C macros, basically.
May 07 2012
next sibling parent "Arne" <arne linux.nu> writes:
On Monday, 7 May 2012 at 20:20:34 UTC, Mehrdad wrote:

 On Monday, 7 May 2012 at 16:52:18 UTC, Arne wrote:

 I think you'd need to modify the compiler for this, since 
 alloca is 'magical'.


 wouldn't mixin's be a solution, one can inject an alloca to 
 the current scope, and then call the constructor...


 Yeah, but mixins are so hacky.
 They're like C macros, basically.


/rant

Well, I think if the world had never seen all the bad
side-effects from 'C macros', most people would wholeheartedly
embrace mixin's today... since it cleanly avoids 'x' number of
design pitfalls from #define.

For maintenance, performance, portability considerations I
definitely prefer mixin's over reimplementing alloca for every
current and future targets/calling conventions.
May 07 2012
prev sibling parent "Chris Cain" <clcain uncg.edu> writes:
On Monday, 7 May 2012 at 20:20:34 UTC, Mehrdad wrote:

 Yeah, but mixins are so hacky.
 They're like C macros, basically.


I'd have to say that C macros have many, _many_ more pitfalls 
than mixins.
May 07 2012
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 07/05/2012 13:58, Gor Gyolchanyan a écrit :

 I'm working on dynamic memory layout manager. Simply put, it will
 allow one to create and use struct types at run-time.
 Normally, you create a struct at compile-time type by specifying an
 ordered list of fields, each with its own type (basically a size) and
 name.
 You then access those fields by calling a compile-time evaluated dot
 operator, which computes the address of the specified field given the
 address of the struct.
 What I'm trying to make is precisely that, except at run-time.

 My question is: what is the best way of allocating such a structure on
 the stack? It will, of course, have a dynamically known size.


About that, I already had the need to return a variable that will be 
qualified as scope after the return.

It would also be usefull to safely implement stack allocator.
May 07 2012
parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Yes! I really want it! There are tons of instances when a heap
allocation is done instead of stack allocation because of dynamic size
alone. If its lifetime is limited by a scope (any scope) - it doesn't
belong on the heap!

On Tue, May 8, 2012 at 2:07 AM, deadalnix <deadalnix gmail.com> wrote:

 Le 07/05/2012 13:58, Gor Gyolchanyan a =C3=A9crit :


 I'm working on dynamic memory layout manager. Simply put, it will
 allow one to create and use struct types at run-time.
 Normally, you create a struct at compile-time type by specifying an
 ordered list of fields, each with its own type (basically a size) and
 name.
 You then access those fields by calling a compile-time evaluated dot
 operator, which computes the address of the specified field given the
 address of the struct.
 What I'm trying to make is precisely that, except at run-time.

 My question is: what is the best way of allocating such a structure on
 the stack? It will, of course, have a dynamically known size.


 About that, I already had the need to return a variable that will be
 qualified as scope after the return.

 It would also be usefull to safely implement stack allocator.




--=20
Bye,
Gor Gyolchanyan.
May 07 2012