Re: J4 - presentation/discussion on "Future of the COBOL Standard"

On Sat, 15 Mar 2008 16:54:24 -0600, "tlmfru" <lacey@xxxxxxx> wrote:


Robert <no@xxxxxx> wrote in message
news:4bbmt3hscg12map55darfj7sqftcdtnhk0@xxxxxxxxxx
On Fri, 14 Mar 2008 12:44:05 -0600, "tlmfru" <lacey@xxxxxxx> wrote:

Referring strictly to the question of "occurs depending on" and
allocation
of memory for it: seems to me it's a non-issue. With the availability of
virtual memory, there is obviously no problem with allocating the maximum
array size: all that's actually needed in the compiled program is a
pointer
of some sort to the virtual memory segment that it's stored in.

You talk like a Computer Scientist.

Thank you. I think. Or are you saying that comnputer scientists are wrong?

They are dismissive of old technology, where old is defined as 'before my time'.

Dynamically
expanding or contracting an array with vm is a pretty problem in
under-the-cover programming but nothing more.

There is MUCH more involved when the address of the array can change.

Maybe so. But it's all handled by the vm manager/paging subsytem.

Sure. Just drop a symbolic link at the old address, pointing to the new address.

Cobol ODOs are not dynamically re-allocatable. The standard says their
address is static.

The virtual storage manager
looks after all the messy details and the "depending on" dataname
specifies
the "actually used" number of entries. I dare say the number of pointers
to
vm segments is unlimited since they also can be stored in a vm segment.

Of course there are performance issues here but on the other hand truly
gigantic physical memory spaces are no longer news.

There are HUGE performance issues with the kind of abstractions you're
talking about.
Today I opened a Java page that took TWO MINUTES to load. When it tried to
use its Send
Email function, it crapped out and provided a stack trace that was at
least 100 entries
deep.

I'm a techie and I couldn't figure out what the problem was. A typical
dumb user wouldn't
stand a chance.

Pray tell - what does this anecdote have to do with varying-size arrays and
vm?

It was a general swipe at excessive abstraction.

Unless I've missed something crucial in the discussion - only those
compilers that actually allocate space as part of the compiled unit will
run
into problems with this.

No compiler does that today. Its output program could become a shared
dll/so thing with a
copy of working-storage for each user process.

But ODOs *are* statically allocated within that data space. They are not
dynamic.

The compiled program does not have to know anything about where the array is
actually stored in memory, real or virtual. And even if the space is
allocated statically, in one maximum-sized glump, the vm manager will smear
it out all over the paging devices. I'm talking operating system functions,
not prorgam-controlled functions. Can you say "memory leak?"

Can you say "pointer?" A pointer IS awareness of where the thing is stored in memory. When
a program calls another passing the structure, it doesn't pass the structure's name, it
passes the address. If the called program causes that address to change, there must be a
way to communicate the new address back to the caller.

You talk as though there is a layer of indirection between the program and memory, a layer
that translates 'handles' into memory addresses. Yes, there is such a layer in hardware,
but for backward compatibility the handles are made to look like a linear address space.
The reason is so programs can do arithmetic on them. If you allow arrays, the implication
is that the location of element n can be computed. If each element has a unique handle
then you have an array of handles. How do you find handle n if not by arithmetic? A string
is an array of bytes. How do you propose finding byte 2 if not by adding 1 to the address
of byte 1?

A byte is an association of bits. In a world of perfect abstraction, each bit would have a
handle. Then there would be only two bits of real data in memory: a 0 and a 1. Everything
else in the computer would be associations of handles to those two bits.
.

Relevant Pages

  • Re: J4 - presentation/discussion on "Future of the COBOL Standard"
    ... there is obviously no problem with allocating the maximum ... array size: all that's actually needed in the compiled program is a ... compilers that actually allocate space as part of the compiled unit will ... The compiled program does not have to know anything about where the array is ...
    (comp.lang.cobol)
  • Re: Superstitious learning in Computer Architecture
    ... There is precious little difference between a ramless cache-only system and a system with no cache memory but with memory management hardware for virtual addressing - mostly just labeling the same boxes differently! ... I was envisioning little square patches of real-estate that would be a logarithmic ALU surrounded by some relatively small memory blocks and connections to adjacent blocks via memory block switching. ... compilers, but a lot of the modern compilers are very much that good. ... That leaves long-reaching scatter/gather - the big challenge for all array processors. ...
    (comp.arch.arithmetic)
  • Re: Strange result from coding error?
    ... appearing in compilers by 2023.) ... checking is done that "it might be nice" if the array had zero size. ... "uninitialized" state, but that allocatables can't? ... If time and memory are not a problem, ...
    (comp.lang.fortran)
  • Re: Difference?
    ... > allocating memory for an array of objects. ... > that malloc will align the memory assuming that the memory allocated ...
    (comp.lang.c)
  • Re: Why delete [] for aray?
    ... Does he use of delete instead of deletewill cause a memory leak? ... the pointer points to an array. ... Moreover, when allocating arrays of classes with non-trivial destructor, ...
    (microsoft.public.vc.language)