segfault with large-ish array with GNAT
in [ADA]
|
From: Jerry on 19 Mar 2010 15:22 On Mar 19, 5:04 am, Brian Drummond <brian_drumm...(a)btconnect.com> wrote: > On Wed, 17 Mar 2010 23:45:25 -0700 (PDT), Jerry <lancebo...(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 Cool tip. Thanks. Jerry
From: Warren on 19 Mar 2010 16:10 Simon Wright expounded in news:m2bpeknq9p.fsf(a)pushface.org: > 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. That was the way with the IBM-1130 as well. Not too good for recursive calls though. Warren
From: Jeffrey R. Carter on 19 Mar 2010 16:22 Brian Drummond wrote: > > But code using the array can be written as normal, with a "my_array ... renames > my_array_ptr.all" clause to hide the pointer. Generally, after something like A : constant Array_Ptr := new Array_Type [(Low .. High)]; You can use A just as if it were the array itself: B := A (A'First); A (A'First) := A (A'Last); A (A'Last) := B; -- Jeff Carter "If you think you got a nasty taunting this time, you ain't heard nothing yet!" Monty Python and the Holy Grail 23
From: Warren on 19 Mar 2010 16:24 expounded in news:ho0c5p$r8$1(a)speranza.aioe.org: > IIRC, the Burroughs 6500 had what they called a "cactus stack" where > branching would occur for new threads. Looking up "cactus threads" reveals that it is also known as a "spaghetti stack". Looking at the picture on wikipedia seems to suggest exactly what I envisioned. http://en.wikipedia.org/wiki/Spaghetti_stack > 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. Wasn't that the TMS9900? It also had this neat X instruction, that could execute one instruction pointed by another register, but control returned to the instruction following the X instruction itself. Effectively execute and return from an arbitrary instruction. I'm not sure what happens if X invoked a "call" instruction of some sort. Thanks for the lead on "cactus threads". Warren
From: Warren on 19 Mar 2010 16:38
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. > 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. :-) > Maciej Sobczak * www.inspirel.com Were you thinking Cilk (or Cilk++)? I saw this in passing this afternoon. One reference indicates a Cilk project existing since '94 using gcc. Looks like good reading material for this weekend. Warren |