[ale] OT: C not C++ Question

Chuck Huber chuck at cehuber.org
Mon Dec 30 12:40:31 EST 2002


On Mon, Dec 30, 2002 at 09:17:28AM -0500, John Mills wrote:
> Danny -
> 
> Thanks for the pointer on 'alloca'.

One thing to keep in mind though with alloca - if you have it in a loop
you could easily run out of stack space.  If I recall correctly, your
user-level apps have 4k of stack space for each process.

I'm not familiar with the alloca() stuff and don't know if there's a
freea().  I'm not sure one could be implemented after considering:

    ptr1 = alloca(...);   // uses stack space
    ptr2 = alloca(...);   // uses more stack space
    freea(ptr1);          // How can you free a block on the
                          // stack that's underneath some other block?

> A three-fold approach used in some embedded designs is:
> 
>  1) Fix the allowable number of each type of allocated variable,
>  2) Allocate the space in a suitably linked list (such as a
>     'short-circuited' ring) in your code's initialization, and
>  3) Provide a mechanism to selectively use and free space in any given
>     list (ring), returning a success or error indication to allocation
>     calls.
> 
> Maybe a picture (Is this really any better???):
> 
>  typeAring ->a1->a2-> ... ->aj-> ... ->an-+
>              ^               |         |
>              | (in use) ...  V (avail) V
>              +---------------+---------+

This is the same structure we used in the R2K for almost everything.
The biggest downside is that everything's statically allocated for a
busiest-case scenario.  So for 90% of the time, only a fraction of
the available memory resources were used.  It wasn't until after
I joined the project that we actually installed kernel support for a
user-level HEAP.  Even after that, we left all the STREAM buffers statically
allocated in the kernel.  Like John's example, each buffer of a different
size had it's own list, and the buffer was pulled out of the free list when
used by the device driver, and put back into the free list by the read()
system call.  Writing was just the opposite: write() grabbed one out of
the list, and the device driver put it back.

For user level apps, until we had a HEAP, everything was either automatic
on a 4k stack, or static.

> (This was in 8080 assembler code in a previous Universe.)

I've done my share of 8080 and z80 assembler code.  That's when
programming was *really* fun.

Enjoy,
    - Chuck

-- 
"The purpose of encryption is to protect good people
from bad people, not to protect bad people from the government."
     Scott McNealy, CEO Sun Microsystems
"The best way for government to control people is to remain in
   a constant threat of war." ---Karl Marx
(18 USC 242), which applies to government agents overstepping their
authority:
  "Whoever, under color of any law, statute, ordinance, regulation,
  or custom, willfully subjects any person in any State, Territory,
  or District to the deprivation of any rights, privileges, or
  immunities secured or protected by the Constitution or laws of
  the United States, . . . shall be fined under this title or
  imprisoned not more than one year, or both . . ."

 PGP signature




More information about the Ale mailing list