Re: "Too many continuation lines" error message (no solution, just comment)
From: glen herrmannsfeldt (gah_at_ugcs.caltech.edu)
Date: 04/16/04
- Next message: Ken Plotkin: "Re: questions on binary vs text files"
- Previous message: Eric: "questions on binary vs text files"
- Maybe in reply to: Paul Van Delst: "Re: "Too many continuation lines" error message (no solution, just comment)"
- Next in thread: Richard Maine: "Re: "Too many continuation lines" error message (no solution, just comment)"
- Reply: Richard Maine: "Re: "Too many continuation lines" error message (no solution, just comment)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 16 Apr 2004 03:59:43 GMT
Richard Maine wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>In the F66 days, with static allocation, compilers I knew compiled
>>DATA to initialize the static data.
> They still do. And anything with initialization is automatically
> "static". Well, technically it is SAVEd, which doesn't *HAVE* to
> mean static - I have worked on systems where it didn't, but I
> know of no systems today where SAVE isn't implemented as static.
I wss never too sure about SAVE. The easy answer is to still
statically allocate everything, and not worry about SAVE.
In C, which allows recursion, automatic variables must be
generated for each instance, and the initial values copied in.
>>Pretty efficient where
>>the numbers varied, not so efficient if they are all the same.
>>I did once initialize a large array to zero in a DATA statement
>>and then punch out the object deck on real cards. A large number
>>of cards were needed for those zeros. Most likely a loop to
>>initialize an array is faster than the process of loading the
>>executable file from disk.
> I have seen compilation of an otherwise modest program crash a
> server-class system by running it out of temporary disk space.
> That's just compilation. Large static arrays can be *VERY*
> inefficient aand often are on current architectures. I made a
> trivial change to that code to initialize the arrays with loops
> instead of DATA statements (this case wasn't huge aero tables,
> which would have had different values all over - these arrays were
> mostly initialized to simple patterns - not quite all zeros, but
> simple enough to express in trivial loops.) Reduced the size of
> the executable image from 30 mb down to about 1. Compile time
> dropped by a few orders of magnitude also - I forget how many,
> but more than one (and I'm not counting the cases of "infinite"
> compile times from when the compilation crashed the system).
So it was about 29MB of static data? In the F66 days I don't
think anyone would think about doing that, except possibly
on a Cray-1.
The worst I had was a C compiler on an Alpha, which would
happily allocate many gigabytes dynamically, but refused
to even compile 100K of static data. It didn't crash
the compiler, but it wouldn't compile it, either.
-- glen
- Next message: Ken Plotkin: "Re: questions on binary vs text files"
- Previous message: Eric: "questions on binary vs text files"
- Maybe in reply to: Paul Van Delst: "Re: "Too many continuation lines" error message (no solution, just comment)"
- Next in thread: Richard Maine: "Re: "Too many continuation lines" error message (no solution, just comment)"
- Reply: Richard Maine: "Re: "Too many continuation lines" error message (no solution, just comment)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]