Inline Assembly - Runtime Stack Allocation

[Brian Lindahl]

I'm using a temporary buffer to transfer some data and would rather
not allocate it on the heap. The problem is that the size of the
buffer is only known upon entry into the function that utilizes it and
I'd rather not waste space or dynamically allocate on the heap (since
it doesn't need to persist). Now I'm planning on utilizing inline
assembly to modify the stack pointer directly to allocate the space I
need.

Here's an example:

void doSomeStuff(unsigned size) {
char* rawData;
//INLINED (Intel p4 assembly)
//sub esp, dword ptr [size]
//mov dword ptr [rawData], esp

//do some stuff with the temporary buffer, using rawData to access
it

//INLINED (Intel p4 assembly)
//add esp, dword ptr [size]
}

As far as I know, it should work just fine, like magic - no problems
at all. BUT, is this assumption correct? Are there any odd quirks that
I should be aware of that I may not have thought of?

 

[Joona I Palaste]

I'm using a temporary buffer to transfer some data and would rather
not allocate it on the heap. The problem is that the size of the
buffer is only known upon entry into the function that utilizes it and
I'd rather not waste space or dynamically allocate on the heap (since
it doesn't need to persist). Now I'm planning on utilizing inline
assembly to modify the stack pointer directly to allocate the space I
need.

Inline assembly is inherently implementation-specific and thus off-topic
on comp.lang.c. Please ask in a newsgroup dedicated to your own
implementation.

 

[Severian]

I'm using a temporary buffer to transfer some data and would rather
not allocate it on the heap. The problem is that the size of the
buffer is only known upon entry into the function that utilizes it and
I'd rather not waste space or dynamically allocate on the heap (since
it doesn't need to persist). Now I'm planning on utilizing inline
assembly to modify the stack pointer directly to allocate the space I
need.

Here's an example:

void doSomeStuff(unsigned size) {
char* rawData;
//INLINED (Intel p4 assembly)
//sub esp, dword ptr [size]
//mov dword ptr [rawData], esp

//do some stuff with the temporary buffer, using rawData to access
it

//INLINED (Intel p4 assembly)
//add esp, dword ptr [size]
}

As far as I know, it should work just fine, like magic - no problems
at all. BUT, is this assumption correct? Are there any odd quirks that
I should be aware of that I may not have thought of?

comp.lang.asm.x86 is right over there ----->

 

[Richard Bos]

I'm using a temporary buffer to transfer some data and would rather
not allocate it on the heap. The problem is that the size of the
buffer is only known upon entry into the function that utilizes it and
I'd rather not waste space or dynamically allocate on the heap (since
it doesn't need to persist). Now I'm planning on utilizing inline
assembly to modify the stack pointer directly to allocate the space I
need.

This is usually a very, very bad idea. What actual reasons have you for
_not_ using malloc(), which is quite nicely suited to this task? Come to
think of it, since you're using this space only as a transfer buffer,
why can't you transfer your data in fixed-size chunks?

Richard

 

[jacob navia]

In C you can write:

int fn(int siz,char buf[siz])
{
}

This will provoke the generation of a similar assembly to what you write.

Note that your assembly code will not work under
the windows operating system making the program crash if
the size is bigger than 4096 bytes.

If you are a windows user you can look at the assembly
generated for the above function by lcc-win32: you will see
that instead of a subtraction from esp a call to _alloca
is generated.

The _alloca function will subtract at most 4096 bytes from the stack
at each time, then TOUCH the page, then subtract more. This avoids
crashing.

http://www.cs.virginia.edu/~lcc-win32

 

[Richard Bos]

In C you can write:

int fn(int siz,char buf[siz])
{
}

Only in C99, though.

This will provoke the generation of a similar assembly to what you write.

This is by no means guaranteed. What it will do is provide similar
_semantics_; the assembly code used to put these into effect are
off-topic on this newsgroup.

Richard

 

[Old Wolf]

In C you can write:

int fn(int siz,char buf[siz])
{
}

Only in C99, though.

This code is valid in both C90 and C99, and is the same as:

int fn(int size, char *buf) {}

This is by no means guaranteed. What it will do is provide similar
_semantics_; the assembly code used to put these into effect are
off-topic on this newsgroup.

You might be thinking of:

int fn(int siz)
{
char buf[siz];
}

 

[Chris Torek]

[some vertical-compression editing]

In C you can write:
int fn(int siz,char buf[siz]) { ... }

(e-mail address removed) (Richard Bos) wrote in message

This code is valid in both C90 and C99 ...

No, it is only valid in C99 -- the size parameter in C89 / C90 may
be omitted entirely, or may be a constant-expression (which is
subsequently discarded), but it may not be an identifier (unless
that identifier is in turn a constant, e.g., an enum member).

... and is the same as:
int fn(int size, char *buf) {}

Yes.

Not sure who the pronoun "you" refers to here -- Jacob Navia, Richard
Bos, the USENET reader, some combination of these? -- but to continue:

You might be thinking of:
int fn(int siz)
{
char buf[siz];
}

This is indeed the "right way" to achieve what the original poster
wanted to do. (Whether doing so is a good idea is another matter
entirely.) In C89/C90, the most likely option is the nonstandard
"alloca" function, which typically interferes with a C compiler's
attempts to use a stack pointer for its own purposes. As a result,
calls to alloca() are, if allowed at all, often quite restricted
-- kind of like setjmp(), in other words.

(For instance, given "char *p", a sequence like:

p = strcpy(alloca(len), somestr);

may "blow up" at runtime by destroying the current stack frame,
while:

p = alloca(len);
strcpy(p, somestr);

may work correctly. A great deal depends on the CPU architecture
and C compiler, though. The semantics of C99's VLAs are not entirely
isomorphic to those of alloca(), but do avoid this problem.)

 

[Brian Lindahl]

From what I gather from the groups, is that my solution was unsafe for
more complicated operating systems that have some sort of protection
or paging dynamics. I did some research and found a solution that most
C compilers support (pretty much 99% of all compilers in current use
today).

void *alloca(size_t size) - allocates a block of <size> bytes on the
stack from and returns a pointer to the start of the block, the block
is automatically freed upon return from the function it was called in
(in most implementations)

Here's a slightly informative documentation of one compiler's
implementation:
http://www.datafocus.com/docs/man3/alloca.3.asp

Note that anyone using this should investigate how their compiler
implements alloca(), as it can get sticky when using it within loops
and if statements (due to scoping). Some compilers will release the
memory upon leaving scope (loop-safe), while others will release the
memory upon leaving the function it is called in (can cause stack
bloating when used within loops).

Hope this is helpful for all those who may want to do the same thing.
This function was what I was exactly looking for - rather than
complaining about this being off topic, infer based upon what I was
trying to do that I was looking for C solution to stack allocation and
was going towards the inline assembly route.

From the poor ability of inference in here, it seems the majority of
you would be better suited for the legal profession rather than
engineering profession - I've seen similar attitudes in many posts
here, whats the deal with trying to be as useless as possible?

 

[Jack Klein]

From what I gather from the groups, is that my solution was unsafe for
more complicated operating systems that have some sort of protection
or paging dynamics. I did some research and found a solution that most
C compilers support (pretty much 99% of all compilers in current use
today).

Makes no difference, there is no such thing as alloca() in standard C,
so it's completely off-topic here.

void *alloca(size_t size) - allocates a block of <size> bytes on the

As I said, it's off-topic here.

stack from and returns a pointer to the start of the block, the block
is automatically freed upon return from the function it was called in
(in most implementations)

Non-standard extensions which are different from one implementation to
the next are specifically off-topic here.

Here's a slightly informative documentation of one compiler's
implementation:
http://www.datafocus.com/docs/man3/alloca.3.asp

Note that anyone using this should investigate how their compiler
implements alloca(), as it can get sticky when using it within loops

No, they shouldn't. This group discusses the C language, which is
defined by an ANSI/ISO International Standard. That standard does not
contain alloca(), so it is not C but just another non-standard
extension. That makes it off-topic here.

If you want to discuss non-standard extensions to one compiler or
another, take it to compiler-specific newsgroups. It's off-topic
here.

and if statements (due to scoping). Some compilers will release the
memory upon leaving scope (loop-safe), while others will release the
memory upon leaving the function it is called in (can cause stack
bloating when used within loops).

Yes, that's the problem with non-standard extensions. Even if the an
extension with the same name exists on another compiler, it may very
well not work the same way. Or even be close. That's what the
"non-standard" part of non-standard extension means.

Hope this is helpful for all those who may want to do the same thing.

No, it's not helpful here, it's off-topic wasted bandwidth.

This function was what I was exactly looking for - rather than
complaining about this being off topic, infer based upon what I was
trying to do that I was looking for C solution to stack allocation and
was going towards the inline assembly route.

There is no such thing as either "stack allocation" or "inline
assembly" in C.

From the poor ability of inference in here, it seems the majority of

It has nothing to do with inference. This newsgroup has a topic,
quite well expressed by its name, comp.lang.c. That is, it discusses
the C computer programming language. Now there is absolutely no doubt
at all about what constitutes the C computer programming language. It
is defined by ISO/ANSI/IEC (and a host of other international
standards bodies) standard 9899.

There is no "alloca", "stack allocation", or "inline assembly" in that
standard, so there are no such things in the C programming language,
the topic of this group.

you would be better suited for the legal profession rather than
engineering profession - I've seen similar attitudes in many posts
here, whats the deal with trying to be as useless as possible?

The deal is trying to gently educate klewless newbies that many
newsgroups have topics and those topics should be adhered to.
Unfortunately some are terminally klewless and feel they have the
right to be thanked, worshiped, and adored for barging in with their
off-topic rubbish and persisting after they have been informed that is
it off-topic.

BTW, have I told you that you're off-topic?

*plonk*

 

[Richard Tobin]

Makes no difference, there is no such thing as alloca() in standard C,
so it's completely off-topic here.

I've encountered some idiots in my time, but I never thought I'd hear
anyone complain about discussing alloca() in comp.lang.c. Do you
behave like this in real life?

-- Richard

 

[Default User]

I've encountered some idiots in my time, but I never thought I'd hear
anyone complain about discussing alloca() in comp.lang.c. Do you
behave like this in real life?

Then you're going to meet many more idiots. Try to find out what the
topic of a newsgroup is before posting. And when you make a mistake,
accept the correction humbly, not in a bitchy manner like this.

There wasn't a single thing wrong with what Jack said or how he said it.



Brian Rodenborn

 

[Mark McIntyre]

I've encountered some idiots in my time, but I never thought I'd hear
anyone complain about discussing alloca() in comp.lang.c.

Hm? alloca() is not part of ISO C. If you think its idiotic to discuss it
in a group dedicated to ISO C, explain why.

Do you behave like this in real life?

This /is/ real life. I'm really here, in front of my screen.

 

[Richard Tobin]

Hm? alloca() is not part of ISO C.

Comp.lang.c has been here since before there was an ISO C. If you
want a group that can't discuss any aspect of C that isn't in the ISO
standard, feel free to create your own.

-- Richard

 

[Ben Pfaff]

Comp.lang.c has been here since before there was an ISO C. If you
want a group that can't discuss any aspect of C that isn't in the ISO
standard, feel free to create your own.

You must be new around here.

 

[jacob navia]

Comp.lang.c has been here since before there was an ISO C. If you
want a group that can't discuss any aspect of C that isn't in the ISO
standard, feel free to create your own.

I would say that since this newsgroup is not a moderated one,
anyone is free to post what he/she wants.

Some people will say that "the subject of this group is ISO C",
some others (like me) will say that the subject of this group
is the C language, and not some subset of it as defined
by ISO C.

alloca() belongs to this group, since it is present in almost all
implementations of the C language I know of.

I would propose that we avoid insulting each other however...

 

[Mark McIntyre]

Comp.lang.c has been here since before there was an ISO C. If you
want a group that can't discuss any aspect of C that isn't in the ISO
standard, feel free to create your own.

Either you're a troll, or you're an idiot. Which is it?

 

[Mark McIntyre]

I would say that since this newsgroup is not a moderated one,
anyone is free to post what he/she wants.

You can certainly post whatever you want to.

Some people will say that "the subject of this group is ISO C",
some others (like me) will say that the subject of this group
is the C language, and not some subset of it as defined
by ISO C.

What you define it as is of no consequence. Nor is what I define it as. The
group's topic is well known, well defined and it is ISO/Ansi C, and at a
pinch K&R C. See the welcome message.

alloca() belongs to this group, since it is present in almost all
implementations of the C language I know of.

If you want to insist on talking about unix extensions to ISO C here, then
feel free to get some really good heatproof clothing first.

 

[jacob navia]

On Sat, 3 Jul 2004 10:16:18 +0200, in comp.lang.c , "jacob navia"


If you want to insist on talking about unix extensions to ISO C here, then
feel free to get some really good heatproof clothing first.

Unix extensions?

Microsofts compilers, Borland compilers and all windows compilers
I know of have featured alloca since quite a long time.

alloca exists in the Cray OS, in the Atari OS I used some centuries ago.

Actually I have never seen a serious compiler without it.

 

[jacob navia]

On 3 Jul 2004 01:18:26 GMT, in comp.lang.c , (e-mail address removed)
(Richard Tobin) wrote:


Either you're a troll, or you're an idiot. Which is it?

Can't we speak without insults?

Thanks for your understanding.

I find the only thing *really* OFF TOPIC are insults.