This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [Patch, fortran] Module loading improvements part 1/3
- From: Janne Blomqvist <blomqvist dot janne at gmail dot com>
- To: Thomas Koenig <tkoenig at netcologne dot de>
- Cc: Tobias Burnus <burnus at net-b dot de>, Mikael Morin <mikael dot morin at sfr dot fr>, Fortran List <fortran at gcc dot gnu dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 27 Mar 2013 00:27:18 +0200
- Subject: Re: [Patch, fortran] Module loading improvements part 1/3
- References: <CAO9iq9H=9=NG5Xc+SXycEAgdgJUq0vjTh0YxsWha38XhbEp_qw at mail dot gmail dot com> <5151B9D1 dot 1010708 at sfr dot fr> <5151BD9F dot 5070702 at net-b dot de> <5151D978 dot 2080802 at netcologne dot de>
On Tue, Mar 26, 2013 at 7:23 PM, Thomas Koenig <tkoenig@netcologne.de> wrote:
> Am 26.03.2013 16:24, schrieb Tobias Burnus:
>
>
>> I wonder whether one should also do what Joost has proposed:* Changing
>> "allocatable" to "al" etc. That reduces both the .mod file size (and
>> thus I/O and improves caching) and the memory consumption of the
>> compiler with the proposed caching scheme. As context-aware compression,
>> it could even have a better ratio than ZIP. (ZIP can still be used on
>> top of it.)
>
>
> I have been thinking a little bit about a complete redesign of the
> module files.
Yes, the more I dig into module.c the more I agree with that sentiment.. :-/
> Ideally, I would like it to be an extensible binary format, which uses
> a keyword-value combination and which could be accompanied by a "dumper"
> which makes it human-readable. A simple yacc grammar could handle
> both the reading and making the "dumper".
>
> If this is designed right, it might not even be necessary to bump the
> module number for old library files.
I'd suggest not inventing our own wheel but rather using an existing
one such as Google's protocol buffers.
https://developers.google.com/protocol-buffers/docs/overview
--
Janne Blomqvist