dailey@lasspvax.UUCP (John Dailey) (03/28/85)
{ Here's one for you }
We are trying to get efl (Extended Fortran Language) running on our
machine. We are using BSD 4.2 Unix. When we try compile an efl program
The compiler dies. It seems that the allocation routine is trying to give
all the available space to the first variable. Any ideas on a fix?
Sorry if this question has already been answered. We are new on the
network. Thanks in advance.
Here is a sample program we got from S. Feldman's paper The Prog. Lang. EFL:
procedure #main program
character(100) line
while( read( ,line)==0)
write( ,line)
end
And here is what we got:
File efl.e:
calloc(2048 words)
Procedure :
Bad count word 2048
Highwater mark 3375 words. 3163 words left over
***Compiler error on line 3. Line 3: out of memory.
Termination code 15
|----------------------------------------------------------------------------|
| John H. Dailey |
| Center for Applied Math. |
| Cornell U. |
| Ithaca, N.Y. 14853 |
| {decvax,ihnp4,cmcl2,vax135}!cornell!amvax!dailey (USENET) |
| amvax.dailey@cornell.arpa (ARPANET) |
|----------------------------------------------------------------------------|ken@rochester.UUCP (Ken the Vagabond) (03/31/85)
Please post to the net if you have the fix for this. I traced one
memory allocation failure to some hardwired struct sizes left over from
the PDP (has it ever worked on Vaxen? Suns?) but lost interest in
hunting down all the bugs.
Ken
--
UUCP: ..!{allegra,decvax,seismo}!rochester!ken ARPA: ken@rochester.arpa
USnail: Dept. of Comp. Sci., U. of Rochester, NY 14627. Voice: Ken!gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (04/01/85)
Well, gee. Your "efl" example worked just fine under the BRL UNIX System V emulation on 4.2BSD. Why waste time with the broken native version?
guy@rlgvax.UUCP (Guy Harris) (04/01/85)
This may or may not be the cause of this problem, but a bug report was made on EFL a while ago. It seems it has private versions of "calloc", "malloc", "cfree", and "free". Unfortunately, there are places where the standard versions are required. The suggested fix was to modify the "defs" file thus: *** /tmp/,RCSt1a15344 Mon Apr 1 00:36:13 1985 --- /tmp/,RCSt2a15344 Mon Apr 1 00:36:15 1985 *************** *** 64,69 #define FIELDMAX 32768. #define ALLOC(x) (struct x *) intalloc(sizeof(struct x)) extern FILE *diagfile; extern FILE *codefile; --- 64,74 ----- #define FIELDMAX 32768. #define ALLOC(x) (struct x *) intalloc(sizeof(struct x)) + #define calloc efl_calloc + #define alloc efl_alloc + #define malloc efl_malloc + #define cfree efl_cfree + #define free efl_free extern FILE *diagfile; extern FILE *codefile; Which renames the private allocation and freeing routines. System V Release 2 fixed the same bug, but in some different manner. Guy Harris sun!guy
guy@rlgvax.UUCP (Guy Harris) (04/03/85)
> Well, gee. Your "efl" example worked just fine under the BRL UNIX > System V emulation on 4.2BSD. Why waste time with the broken native > version? They might not have the BRL version. (BTW, the System V version does fix the "alloc" bug by making the private versions of "malloc" and "free" (but *not* "calloc") static. Other than that, the biggest change between the 4.2BSD and System V "efl"s is that SCCSIDs were added in System V.) Guy Harris sun!guy
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (04/06/85)
> They might not have the BRL version.
That's no excuse! :-)melanie@cornell.UUCP (06/03/85)
From: melanie (Melanie Nesheim)
I tried to use EFL 1-1/2 years ago, but found bugs that made it
unusable. (I can't remember a whole lot, but it did have to do
with improper allocation of space. Also, there was no way to use
the Fortran "parameter" statement, which was a pain.) It happened
that the fellow who wrote EFL visited Cornell at that time, and when
we asked him about how to fix it he couldn't help us. ("Yeah, well,
it was my first compiler...") So I gave up on EFL and switched to
Ratfor. I am the only one at Cornell (I'm pretty sure) who tried
to use it; I haven't heard of anyone successfully using it since
then.
--Melanie Nesheim