comp.lang.ada
 help / color / mirror / Atom feed
* Unconstrained Objects
@ 1995-03-31  0:00 Eric Shulman
  1995-04-04  0:00 ` Robert Dewar
       [not found] ` <3lt22a$18p@maple.enet.net>
  0 siblings, 2 replies; 7+ messages in thread
From: Eric Shulman @ 1995-03-31  0:00 UTC (permalink / raw)


Does anyone know if modern Ada compilers allocate objects of
the largest possible size for an unconstrained object.
I would appreciate the names of any compilers if possible.
I am currently using Meridian PDK 4.1.4 and GNAT 2.00.

Thank you

Eric Shulman




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Unconstrained Objects
  1995-03-31  0:00 Unconstrained Objects Eric Shulman
@ 1995-04-04  0:00 ` Robert Dewar
  1995-04-06  0:00   ` HUMPHREY_TERRY
       [not found] ` <3lt22a$18p@maple.enet.net>
  1 sibling, 1 reply; 7+ messages in thread
From: Robert Dewar @ 1995-04-04  0:00 UTC (permalink / raw)


GNAT allocates the maximum size for unconstrained variant records. We
consider this the preferable implementation, since hidden use of the3
heap seems intolerable.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Unconstrained Objects
  1995-04-04  0:00 ` Robert Dewar
@ 1995-04-06  0:00   ` HUMPHREY_TERRY
  1995-04-06  0:00     ` Cyrille Comar
  1995-04-07  0:00     ` Robert Dewar
  0 siblings, 2 replies; 7+ messages in thread
From: HUMPHREY_TERRY @ 1995-04-06  0:00 UTC (permalink / raw)


In <3ls78u$nr3@gnat.cs.nyu.edu> dewar@cs.nyu.edu writes:

> GNAT allocates the maximum size for unconstrained variant records. We
> consider this the preferable implementation, since hidden use of the3
> heap seems intolerable.
> 

Does this mean that GNAT does not implicitly allocated from the heap
under any circumstances?  If the answer is no, then under what circumstances
does GNAT implicitly allocate from the heap?

Thanks in advance,
Terry Humphrey




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Unconstrained Objects
  1995-04-06  0:00   ` HUMPHREY_TERRY
@ 1995-04-06  0:00     ` Cyrille Comar
  1995-04-07  0:00       ` Robert Dewar
  1995-04-07  0:00     ` Robert Dewar
  1 sibling, 1 reply; 7+ messages in thread
From: Cyrille Comar @ 1995-04-06  0:00 UTC (permalink / raw)


HUMPHREY_TERRY (HUMPHREY@ASD1.JSC.NASA.GOV) wrote:

: Does this mean that GNAT does not implicitly allocated from the heap
: under any circumstances?  If the answer is no, then under what circumstances
: does GNAT implicitly allocate from the heap?

GNAT allocates outer-level objects with a non-static size on the
heap. This is the only case of implicit allocation that will remains
in the final version.  GNAT used to allocate anonymous objects (for
functions returning unconstrained types) on the heap but it is not the
case anymore, now those objects are alocated on a secondary stack. If
you find other implicit uses of the heap (that is to say, leaks), they
are considered BUGS and should be reported as such to gnat-report.

In fact, there is another case of implicit allocation for the current
implementation of the secondary-stack, if it grows too much, it
allocates a new block on the heap.
In contexts where this is not desired, it is easy to provide another
implementation of the secondary-stack (in s-secsta.ad?) which is a
regular storage pool. No change to the compiler itself is needed, you
don't even need to recompile it...

--
------------------------------------------------------------------------
Cyrille Comar,                                  E-mail: comar@cs.nyu.edu
Gnat Project                                    US phone: (212) 998-3489





^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Unconstrained Objects
       [not found] ` <3lt22a$18p@maple.enet.net>
@ 1995-04-06  0:00   ` Robert Dewar
  0 siblings, 0 replies; 7+ messages in thread
From: Robert Dewar @ 1995-04-06  0:00 UTC (permalink / raw)


Dan is wrong on several points. Most notably, it is perfectly legal for
a compiler to use a represetnation for a subtype that is different from
the basee type, and in certain cases (constrained subtypes of unconstrained
variant records with default discriminants), it is a common implementation.
But some compilers will even use a different representation for subtypes
of integer, and this is perfectly legitimate.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Unconstrained Objects
  1995-04-06  0:00   ` HUMPHREY_TERRY
  1995-04-06  0:00     ` Cyrille Comar
@ 1995-04-07  0:00     ` Robert Dewar
  1 sibling, 0 replies; 7+ messages in thread
From: Robert Dewar @ 1995-04-07  0:00 UTC (permalink / raw)


"Under what conditions does GNAT implicitly allocate from the heap"


Very few, we consider implicit heap allocations to be a bad thing. Here is
the complete list:

  1.  When a task is created, its dynamic storage is allocated from the heap

  2.  When the secondary stack for the main task has to be expanded, we
	get space from the heap (we will probably restrict this in a 
	future version).

  3.  At the start of execution, we use malloc to allocate space for
	dynamically sized global objects.






^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Unconstrained Objects
  1995-04-06  0:00     ` Cyrille Comar
@ 1995-04-07  0:00       ` Robert Dewar
  0 siblings, 0 replies; 7+ messages in thread
From: Robert Dewar @ 1995-04-07  0:00 UTC (permalink / raw)


Cyrille forgot the task creation case, but otherwise our two posts agreed!





^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~1995-04-07  0:00 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1995-03-31  0:00 Unconstrained Objects Eric Shulman
1995-04-04  0:00 ` Robert Dewar
1995-04-06  0:00   ` HUMPHREY_TERRY
1995-04-06  0:00     ` Cyrille Comar
1995-04-07  0:00       ` Robert Dewar
1995-04-07  0:00     ` Robert Dewar
     [not found] ` <3lt22a$18p@maple.enet.net>
1995-04-06  0:00   ` Robert Dewar

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox