Looking for free memory pool software

[CBFalconer]

.... snip ...

A stack the only way of implementing a conforming C compiler.
Those that do not use stacks do not support recursion.
Read my book "Basic Algorithms" if confused about stacks and how
they are useful.

You are showing total ignorance here. C runs on machines without
stacks, and recursion is required.

 

[pete]

Further, if you're going to use "some of us has [sic] been
trained in linguistics" as an attempt to shut down those who
disagree with you, you should be prepared for the use of "some
of us have been trained in computer science" as an attempt to
shut down your next bit of wingnuttery -- or the next iteration
of one of your previous bits of wingnuttery. Or for someone to
say, "you know, Malcolm, I've been trained in linguistics and I
speak, read, and write four languages, and you're full of it."
Whoops, I just did.

M> A "linguist" is not someone who knows lots of foreign
M> languages, at least in sense in which I am using the term. You
M> can't have had any exposure at all to lingustics if you don't
M> know something as elementary as that.

Notice, please, the coordinating conjunction 'and.' Had I really
meant to imply that I was trained as a linguist *because* I spoke,
read, and wrote four languages, I would have no doubt used that
subordinating conjunction instead.

You may be casually sloppy in your use of language; it is a
significant error to assume that others are as well.

I used to be a sea lawyer.
Now I'm a C language lawyer.

 

[CBFalconer]

.... snip ..

You and KB are pedants in the bad sense of the term. In this case
I was explaining how most data objects can be structured in a
stack, allowing a very simple and efficient memory management
paradigm. The question then arises, why not make the objects
automatic? However there is not much point using the standard's
term "automatic storage duration", because it may not be familiar,
as anyone with any common sense would realise.

No, you are the short-sighted one. C does not require a stack. It
does require various storage classes, known as static, automatic,
and that provided by malloc. The C standard is deliberately
written using those terms, in order not to inhibit the creativity
of hardware designers. No reference to 'stacks' is made.

For example, look at the design of the IBM 360 series.

 

[Richard Heathfield]

Malcolm McLean said:

A "linguist" is not someone who knows lots of foreign languages,

Er, actually that's exactly what a linguist is, according to Chambers:
"someone who has a good knowledge of languages".

The word *also* means "someone who studies linguistics" and "an
intermediary between chief or priest and the people"(!).

You would carry a lot more credibility if you stopped talking nonsense.

 

[Malcolm McLean]

I think it would have been more helpful to point out the relationship
between the term "automatic storage" and the common arrangement of
putting such objects on a stack. You'd have explained a term the OP
will have to come to terms with eventually and you would look less like
someone who wants to a start a row.

The question was how to build a memory mangement system from scratch.

The best way very much depends on what you value, but one of the simpest and
fastest methods is to use the stack allocator. That leads to the question,
why not just make everything automatic, or as I said "put on the C stack".
The OP, if he is thinking of a memory system, will know that C compilers use
a stack, he won't necessarily know that this isn't mandated by the standard,
and that's a different topic to the one he is interested in.

Whilst you can argue that I should have used a more technical, precise term,
the case for the everyday term was pretty clear. Hence it is just a form of
points scoring to demand where "stack" is defined in the C standard. It is
irritating, so I respond that it is naive about language, to irritate them
back. Though in my case the point is true.

The response was "I've been trained in linguistics and speak, read, and
write four languages". Well of course that says it all. No one who knows
what linguistics is would say that, though it is a common error made by
those outside.

 

[Chris Dollin]

No, you are the short-sighted one. C does not require a stack. It
does require various storage classes, known as static, automatic,
and that provided by malloc. The C standard is deliberately
written using those terms, in order not to inhibit the creativity
of hardware designers. No reference to 'stacks' is made.

For example, look at the design of the IBM 360 series.

Specifically, C does not require that the underlying machine has
a hardware stack or instructions specialised for stack operations,
and it does not require that any stack it /does/ use is composed
from a single contiguous section of memory.

It's hard to implement C efficiently without implementing a stack
of some kind, or relying on garbage-collection. Since most C
implementations don't have the luxury of a to-hand GC, and don't
need to implement one for C, it would be pretty close to madness
not to implement a (possibly discontiguous, possibly within the
heap) stack.

It's perfectly possible to implement a stack on the IBM 360; I'd
lay odds that a 360 C implementation does so.

 

[Charlton Wilbur]

M> The response was "I've been trained in linguistics and speak,
M> read, and write four languages". Well of course that says it
M> all. No one who knows what linguistics is would say that,
M> though it is a common error made by those outside.

I reiterate: it's a coordinating conjunction, not a subordinating one.
It shows practical experience, as it were.

Charlton

 

[CBFalconer]

.... snip ...

It's perfectly possible to implement a stack on the IBM 360; I'd
lay odds that a 360 C implementation does so.

It doesn't, to the best of my knowledge. It reserves a register to
point to a chunk of memory for saving things, which it then uses
before calling other things. Or something of the ilk. A new
routine saws off a new chunk for itself. These are effectively
similar to malloc allocations.

 

[Barry Schwarz]

[snips]

1) For quite a lot of objects you know their memory requirements on
creation, and you can arrange them in a stack so that the first created
is
also the last destroyed. Thus you can use a stack for allocating these
objects, it the most efficient answer. You could in theory put them on
the
main C stack

What, exactly, is "the main C stack" and where in the standard is it
defined?

A stack the only way of implementing a conforming C compiler. Those that do
not use stacks do not support recursion.
Read my book "Basic Algorithms" if confused about stacks and how they are
useful.

Just one more person who believes the limits of his experience and
imagination have some relevance to the real world.

You might want to have a look sometime at some IBM mainframe manuals
(free from their web site) to learn about a system with no stack that
can store floating point values in decimal to solve the perennial
problem of representing .1 exactly.


Remove del for email

 

[Malcolm McLean]

Just one more person who believes the limits of his experience and
imagination have some relevance to the real world.

You might want to have a look sometime at some IBM mainframe manuals
(free from their web site) to learn about a system with no stack that
can store floating point values in decimal to solve the perennial
problem of representing .1 exactly.

You mean no hardware support for a stack. Not no stack. You can't do
recursion without a stack, even if it is a linked list rather than
contiguous in memory.
Go onto my website and check out the Turing machine.

 

[Richard]

You mean no hardware support for a stack. Not no stack. You can't do
recursion without a stack, even if it is a linked list rather than
contiguous in memory.
Go onto my website and check out the Turing machine.

In the real world, people are taught about stacks as lesson #1. And that
includes C courses. This thread is almost as useless as RHs ridiculous
claim that there are no such things as global variables in C. Word games
can and do have their place. But the use of them needs to be considered
carefully to match the audience.

I would suggest that "no stack" architectures are OT and should be
discussed in a C group dedicated to those very unusual architectures.

 

[Keith Thompson]

You mean no hardware support for a stack. Not no stack. You can't do
recursion without a stack, even if it is a linked list rather than
contiguous in memory.

Exactly. Your earlier failure to make this important distinction is
what led to this tedious argument.

Go onto my website and check out the Turing machine.

In the unlikely event that that's somehow relevant to the current
discussion, it would help to know where your website is. Don't assume
we all have it bookmarked.

 

[Malcolm McLean]

In the unlikely event that that's somehow relevant to the current
discussion, it would help to know where your website is. Don't assume
we all have it bookmarked.

The Turing machine can calculate any computable function, including a C
compiler and virtual machine to run the programs. If you look casually you
will see no stack. Of course there will be stacks, buried in the bit
patterns.

Follow to sig to play with it.
I must admit I never got round to the Turing adder, though I've got a busy
bee.

 

[Barry Schwarz]

snip

I would suggest that "no stack" architectures are OT and should be
discussed in a C group dedicated to those very unusual architectures.

You do realize that in the big picture hosted systems like PCs are a
very small minority. Does that make them unusual too? What's next?
Banning EBCDIC because 'J' doesn't immediately follow 'I'?


Remove del for email

 

[Richard Heathfield]

Barry Schwarz said:

snip


You do realize that in the big picture hosted systems like PCs are a
very small minority. Does that make them unusual too? What's next?

How about "not feeding trolls"? That might work.

Banning EBCDIC because 'J' doesn't immediately follow 'I'?

In EBCDIC, I is immediately followed by C, making it topical.

 

[Kelsey Bjarnason]

[snips]

In the real world, people are taught about stacks as lesson #1. And that
includes C courses.

Hmm. True. However, once one gains a certain level of skill and
experience, one comes to realize that what one learns in lesson #1 is not
the totality of what there is to learn. One such thing we learn is that
C defines no concept of stack, nor does it require one, as there are
systems which have no stack, yet which can - and do - have conforming
implementations.

Malcolm again creates confusion by terminology. Those implementations
_may_ use a stack data structure to track recursion and the like, but if
so, that's an implementation detail; the language, which we discuss here,
neither defines nor requires any such data structure, nor hardware stack.

This thread is almost as useless as RHs ridiculous
claim that there are no such things as global variables in C. Word games
can and do have their place. But the use of them needs to be considered
carefully to match the audience.

It isn't a word game, though, any more than to point out that in C, "byte"
is not restricted to 8 bytes, no matter how many people use the two
concepts interchangeably. It is a case of ensuring that the information
provided is either correct, or gets corrected.

I would suggest that "no stack" architectures are OT

Properly speaking, they are; the group is about C. C, however, neither
defines nor requires a stack, so the assumption that such an entity will
be in place on an arbitrary implementation is erroneous. The mentioning
of those systems is simply to show _why_ no such requirement is imposed by
the language.

 

[Richard]

[snips]

In the real world, people are taught about stacks as lesson #1. And that
includes C courses.

Hmm. True. However, once one gains a certain level of skill and
experience, one comes to realize that what one learns in lesson #1 is not
the totality of what there is to learn. One such thing we learn is
that

No. But one also learns that to nitpick with nOObs is nothing more than
posturing and complicating issues.

C defines no concept of stack, nor does it require one, as there are
systems which have no stack, yet which can - and do - have conforming
implementations.

Big deal. Stacks ARE used and nOObs here use system WITH stacks.

Malcolm again creates confusion by terminology. Those implementations
_may_ use a stack data structure to track recursion and the like, but if
so, that's an implementation detail; the language, which we discuss here,
neither defines nor requires any such data structure, nor hardware
stack.

Don't be such a knob jockey. The concept of a stack is paramount to
understanding various C like programming constructs, Whichever way you
want to cut it. To "not talk about stacks" because "its not required by
the standard" is ridiculous.

It isn't a word game, though, any more than to point out that in C, "byte"
is not restricted to 8 bytes, no matter how many people use the two
bits.

concepts interchangeably. It is a case of ensuring that the information
provided is either correct, or gets corrected.


Properly speaking, they are; the group is about C. C, however, neither
defines nor requires a stack, so the assumption that such an entity will
be in place on an arbitrary implementation is erroneous. The mentioning
of those systems is simply to show _why_ no such requirement is imposed by
the language.

"stack" has a general meaning. And I would suggest to you that its
impossible to teach recursion or pretty much anything without
considering a concept like or similar to a "stack".

Why do you have to complicate simple issues?

 

[Keith Thompson]

[snips]

In the real world, people are taught about stacks as lesson #1. And that
includes C courses.

Hmm. True. However, once one gains a certain level of skill and
experience, one comes to realize that what one learns in lesson #1 is not
the totality of what there is to learn. One such thing we learn is that
C defines no concept of stack, nor does it require one, as there are
systems which have no stack, yet which can - and do - have conforming
implementations.

Here I think you're using the word "stack" to mean a hardware stack,
not a last-in first-out data structure.

Malcolm again creates confusion by terminology. Those implementations
_may_ use a stack data structure to track recursion and the like, but if
so, that's an implementation detail; the language, which we discuss here,
neither defines nor requires any such data structure, nor hardware stack.

Objects with automatic storage duration are allocated and deallocated
in a strict last-in first-out (i.e., stack-like) manner. The fact
that the standard doesn't use the word "stack" doesn't mean that it
isn't one. This "stack" could easily be implemented as, say, a linked
list of heap-allocated chunks of memory at arbitrary locations.

But saying that local variables are allocated "on the stack" is
misleading, since that *usually* refers to a hardware stack.

The C standard doesn't use the word "subroutine", but if someone asked
whether C supports suboutines, it would be absurd to say that it
doesn't.

It isn't a word game, though, any more than to point out that in C, "byte"
is not restricted to 8 bytes, no matter how many people use the two
concepts interchangeably. It is a case of ensuring that the information
provided is either correct, or gets corrected.


Properly speaking, they are; the group is about C. C, however, neither
defines nor requires a stack, so the assumption that such an entity will
be in place on an arbitrary implementation is erroneous. The mentioning
of those systems is simply to show _why_ no such requirement is imposed by
the language.

Exactly.

 

[Keith Thompson]

Big deal. Stacks ARE used and nOObs here use system WITH stacks.

[...]

C programmers need to understand that objects with automatic storage
duration (local variables, if you prefer) are allocated and
deallocated in a stack-like last-in/first-out manner. They *don't*
need to assume that this is implemented via the typical hardware
stack.

I notice that nobody here has said anything about whether "the stack"
grows toward higher or lower addresses. That's because the direction
in which the hardware stack grows is an implementation detail; it's
not relevant to most C programming, and it's certainly not something
that beginners should be worrying about. The existence of a hardware
stack (as opposed to, say, a linked list of heap-allocated activation
records) is another such implementation detail.

Memory for a function's local variables (including parameters) is
allocated when the function is called, and deallocated when the
function returns. That pretty much covers what you need to know
(unless you're doing some *very* low-level stuff), and I didn't
mention the word "stack", or even go out of my way to avoid doing so.

Knowing about such low-level details is certainly valuable, and it's
helpful to an understanding of why C is the way it is -- but it's
about computer architecture, not about C.

 

[Tony Mc]

Objects with automatic storage duration are allocated and deallocated
in a strict last-in first-out (i.e., stack-like) manner. The fact
that the standard doesn't use the word "stack" doesn't mean that it
isn't one. This "stack" could easily be implemented as, say, a linked
list of heap-allocated chunks of memory at arbitrary locations.

Hi Keith,

I could not find anything in the ISO/IEC 9899:1999 standard that
specified anything about the order of allocation and deallocation of
objects with automatic storage duration. I thought section 6.2.4 would
have been relevant, but the allocation/deallocation order seems to be
unspecified. Similarly, in the C89 standard, I thought 6.1.2.4 would
be relevant, but again it leaves the order unspecified. Could you
point me to the relevant section please? Is there any way of
determining (in standard C) what the order of deallocation is for
objects with automatic storage duration?

Best,
Tony