segfault with large-ish array with GNAT
in [ADA]
|
From: Brian Drummond on 19 Mar 2010 08:04 On Wed, 17 Mar 2010 23:45:25 -0700 (PDT), Jerry <lanceboyle(a)qwest.net> wrote: >But it seems that I will have to allocate memory for large objects >using pointers (and thus take the memory from the heap). Is that >right? I believe so. But code using the array can be written as normal, with a "my_array ... renames my_array_ptr.all" clause to hide the pointer. - Brian
From: Warren on 19 Mar 2010 09:20 Ludovic Brenta expounded in news:bce19c00-0599-4ff6-a5cf-16bb3d742373 @e7g2000yqf.googlegroups.com: > Warren wrote on comp.lang.ada: >> Imagine >> a CPU that somehow in microcode was able to do a fast-malloc >> of a stack frame (as part of a call), linking the new >> frame back to the calling frame. Then you could eliminate >> the need for a "linear virtual stack region" altogether. This >> would allow code to freely fork into many parallel >> threads without the issue of pre-allocating stack [address] >> space to each new thread. When the called procedure executed >> a "return", it would (in microcode) free the current stack >> frame and return to the prior one. �The "call" allocate/free's >> could be constrained to one general "stack heap". > > I wonder how that would work with processors that have register > windows specifically to reduce the need for a memory-based stack (i.e. > SPARC, IA64 and maybe others). > > -- > Ludovic Brenta. I'm not sure I follow, but objects like small buffers would presumably still occupy the current stack frame. Warren
From: Charmed Snark on 19 Mar 2010 09:26 Maciej Sobczak expounded in news:6b9abbbd-2d5e-4e80-b353-fc4d1ccd2963 @q23g2000yqd.googlegroups.com: > On 18 Mar, 18:03, Warren <ve3...(a)gmail.com> wrote: >> With the new focus on parallel cores etc., I've often pondered >> what a future CPU without a stack might look like. Imagine >> a CPU that somehow in microcode was able to do a fast-malloc >> of a stack frame > > There is no need to do that in microcode - the compiler decides what > does it mean to call a subprogram and what does it mean to allocate > the "frame", so you might simply have a compiler that implements these > concepts in terms of a dynamically allocated linked list. True enough.. > I vaguely remember reading about a C compiler that did exactly that a > while ago - but I fail to find it in Google due to the noise from > billions of tutorials with stacks and lists. :-) Interesting. Do you recall the time frame? Was it DOS era or post Win95? > Today you might find this idea implemented in just about any > *interpreter*. > Maciej Sobczak * www.inspirel.com Even interpreters use stacks. A basic interpreter needs to allocate a stack for each thread of control. However, as you say, it could be implemented differently as a linked list of "frames". Warren
From: tmoran on 19 Mar 2010 13:27 IIRC, the Burroughs 6500 had what they called a "cactus stack" where branching would occur for new threads. And there was a Texas Instruments microprocessor that had no real stack, but rather a set of registers that could be saved to RAM on a subroutine call. These preceded DOS.
From: Simon Wright on 19 Mar 2010 14:02
tmoran(a)acm.org writes: > IIRC, the Burroughs 6500 had what they called a "cactus stack" where > branching would occur for new threads. And there was a Texas Instruments > microprocessor that had no real stack, but rather a set of registers > that could be saved to RAM on a subroutine call. > These preceded DOS. The PDP-8 worked like that; the JMS instruction stored the return address in the first word of the subroutine, execution started at the next word. JMS FOO / CALL SUBROUTINE FOO FOO, +0 / STORED RETURN ADDRESS ... JMP I FOO / RETURN (we only had capitals) --S |