Re: Bit Concatenation


AeroSpace Ed wrote:
(stuff I accept in the main; I talk about decompiling when I mean
dis-assembling).

I'm ex-aerospace myself (well, ballistic).

Backgound.
But we use F77 to get small e-mail deliverable executables and
complete systems available from our website in minutes and not hours,
important to students and third-world users without broadband.

We DID compile old code with one of two F95 compilers and never found
code errors, but did find problems with file ERR= and END= combinations
no longer allowed, the meaning of RECL (a compiler parameter changed to
a new 4-byte unit default), the "fact" that any integer constant "was"
integer*4 while a variable "was" integer*2 by default, that some
compilers REFUSE an "Implicit integer" statement (eg elf90) .
Then there was the "Open New" on possibly existing old files and
similar small problems which could not be resolved and still leave
portable code.

In general, I write Fortran code. A current Fortran compiler can compile
the code that I wrote back in 1985 as well as code that I'm currently
writing.

I doubt that, see above exceptions.

I generally use a new compiler, but not necessarily. When I do
use a current compiler, it's generally a F95 compiler, But that really is
no concern to me. I try to write "standard" Fortran. It's made moving and
recompiling code a ton easier.

Funny, I thought that is what we were doing to get portability. Note
lots of clients don't use or want Windows in operations (think of Lab),
only in management areas.

My current personal choice/style is to use features of the Fortran Language
that have been recently added in the latest Fortran Standards.

I don't, but I sure miss some useful ones like label-less DO.

I do not ususally modify old code that was written in the 1980's to "get it to
compile" with the newest compilers.

Never our intention, but F90 needed it (see above).

It usually does (or exposes a bug on my
part! that's been lying around for a long time).

Of course it could happen, but not so far... ( I did ask).

I will modify the old code
to take advantage of newer language features, on occasion, when my "cost
analysis" justifies the labor. Issues like Integer*4 .vs. Integer*2 that
you mention below have nothing to do with F90 versus F77. It's just that
you chose to ignore (and the old compiler of yours didn't think it
important enough) precise argument matching.

Misunderstanding. I WANT integer*2 variables exept for accounting
programs (we also write) in currencies where there are thousands of
local units to the dollar, and for totals in statistical reports
weighted to global universes. Current file system standards in our
industry have some requirements for record sizes which are a multiple
of two, not four bytes. And again, see above; is IS a compiler
condition in some cases. So all Integer*2 variables had to be
specifically specified to allow recompiling.

..
It sounds like you are complaining that more error checking on the compiler
part is bad. This is weird.

OH NO! I never complained about checking programs!
Only about writing new interfaces for nearly two hundred modules.

I suspect that if you ran the newer compiler with just F77
semantics (many allow this), you'd still get the errors. It's just a
better compiler trying to do more of the work for you.

I repeat ( even Robin was suprised); we did and NEVER FOUND ERRORS!
Even after writing the interfaces to permit usage determinations.

The only serious problem we found was the impossibility of using F90
code to do something important to us, of bringing in selectable
language modules for user-program interchange of information. A long
serious of exchanges on a vendor Fortran Forum never found a solution.
This may be a factor in why we still use F77.
It was all about character strings (length built-in) versus character
arrays and stored used-length information. Complex!.

I think that most of the time when you mention F77 you are specifically
talking about your lone, single MSDOS compiler that you have good
experiences with. That's fine, but please don't cast it as a F77/F90
issue. It's not. Keep on writing your FORTRAN code. Find a vendor that
does a good job (in your own mind) of enforcing F77 semantics and forget
that the rest of the world is chugging along.

Oh, We wanted to, but see above. We were quite happy with progress
using Compaq-Digital-HP DVF/CVF apart from executable sizes and were
looking into one or more common DLLs as a size-reducing solutions for
complte system delivery and short-file update (as per Lahey
licence-free kernal) but then Intel took over DVF.

The rest of the complaining about efficientcy and file size as a result of
the newer compilers is along the lines of black and white .vs. color TV.
Black and white was all that anyone ever needed...
I can put 2GB of storage (in fact an entire OS, compilers, IDE, pre and post
processing tools, email, http servers, etc) on my keychain now for $50 and
walk up to any computer (i386) and boot into my development environment.

The key-chain ROM is fine if your computer has a USB bus, but most of
our "little guys", and half our own test computers are USB-less. In
fact there are only two writable CDROM device here. Even my own laptop
is read-only.

Kinda makes your argument about files sizes being too large seem pretty lame.

We should send pre-loaded keychains to our clients?
Bulk e-mail is easier

.

Relevant Pages

  • Re: General advice on C++ F77 multi-language compiling and linking
    ... This last part I am working through separately using help from Mixed language programming using CO++ and FORTRAN 77. ... From what I've been able to learn so far, I'll need a f77 compiler running on Windows-Intel as a minimum. ... MSVS2005 express is the only cheap way with current support; as you may have noticed, MS does not permit Fortran to be used with it, except by command line. ...
    (comp.lang.fortran)
  • Re: General advice on C++ F77 multi-language compiling and linking
    ... Mixed language programming using CO++ and FORTRAN 77. ... From what I've been able to learn so far, I'll need a f77 compiler running ...
    (comp.lang.fortran)
  • Re: f77 <-> g77
    ... Generically, it will refer to a Fortran 77 compiler, but in different ... Fortran 77 compilers. ... saying that someone is using "the f77" compiler is very little ...
    (comp.lang.fortran)
  • Re: Fortran 77 vs Fortran 90/95
    ... Maybe I have the benefits of fortran 90 without the hassle. ... My applications get used by people on lots of different platforms. ... Fine f77 compiler as far as I know. ...
    (comp.lang.fortran)
  • Re: Subroutine Argument Checking
    ... >> I agree with you about F77. ... The cost of the compilers should soon be repaid in the savings ... >It is a subset of Fortran 95, so any valid F program is a valid Fortran ... With a Fortran 90 compiler, you can just put the F77 procedures in a module, ...
    (comp.lang.fortran)