From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22537 invoked from network); 28 Feb 2000 18:23:32 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 28 Feb 2000 18:23:32 -0000 Received: (qmail 11049 invoked by alias); 28 Feb 2000 18:23:23 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9914 Received: (qmail 11032 invoked from network); 28 Feb 2000 18:23:22 -0000 Subject: Re: Precompiled wordcode zsh functions In-Reply-To: <200002281450.PAA03800@beta.informatik.hu-berlin.de> from Sven Wischnowsky at "Feb 28, 2000 03:50:51 pm" To: Sven Wischnowsky Date: Mon, 28 Feb 2000 18:18:29 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Zefram Sven Wischnowsky wrote: >I forgot: there is a problem with this which I remembered at the >weekend. The word-code isn't really machine-independent, it depends on >the endian-ness. Does it depend on the length of int too? >With that a standard installation could: The obvious clean solution is to define an architecture-independent wordcode format so that the saved wordcode is shareable. However, I expect that would have an undesirable amount of overhead. Next possibility is to have saved wordcode files contain wordcode for both endiannesses. Wordcode files get twice as big, but the unneeded half can be so completely ignored that it never gets paged in at all. I don't think that address space usage is a significant concern at this level. Next possibility: separate wordcode files for different endiannesses (and possibly different int sizes). Have .zwcb and .zwcl suffixes. When looking for the file for an individual function, only look for the appropriate suffix; digest files are ignored if they are of the wrong endianness (determined internally). On the issue of digest files versus individual function files, I think we should have both. A .zwc file in a directory in $fpath acts exactly like a normal textual function definition file, except that it is in wordcode instead of text; it should take precedence over any file (of either type) further down $fpath, but we may want to do a date comparison if both textual and wordcode files exist in the same directory. A digest file should actually be listed in $fpath; its definitions take precedence over directories (and digest files) further down $fpath. We should probably have some size theshold to switch between reading and mapping wordcode files; e.g., any file over two pages long gets mmapped. -zefram