User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.8)
            Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
References: <19109.1284579373@cl.cam.ac.uk>
            <4C9122A1.4060008@morningstar2.co.uk>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID:  <4C91239B.2040301@morningstar2.co.uk>
Date:         Wed, 15 Sep 2010 20:50:51 +0100
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@listserv.uni-heidelberg.de>
Sender: Mailing list for the LaTeX3 project <LATEX-L@listserv.uni-heidelberg.de>
From: Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK>
Subject: Re: Allocation of registers
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <4C9122A1.4060008@morningstar2.co.uk>
Precedence: list
Status: R

On 15/09/2010 20:46, Joseph Wright wrote:
> On 15/09/2010 20:36, Robin Fairbairns wrote:
>>> I guess for the time being that is a good approach
>>
>> is there an actual reason that inserts can't start working down from
>> 64k?
>>
>> etex.sty can't do this, because the basic set of inserts has been
>> allocated by the time it gets to run, and that plainly isn't a
>> constraint on latex 3. but does it matter for expl3?
>>
>> (i have once spent time on thinking this issue through, but i'm not well
>> -- still -- and can't remember what conclusion i came to.)
>>
>> robin
>
> At a format level we don't currently have any allocation routine for
> inserts at all, as we've not used them :-) On the other hand, expl3 is
> 'LaTeX3 on 2e' so has exactly the same requirements as etex. (Indeed,
> the whole reason for simply using etex for allocation in expl3 as a
> package is that it avoided making errors in the interaction with the
> LaTeX2e allocation routine.)

I also notice that the e-TeX manual says

'The additional registers, numbered 256–32767, can be used exactly as 
the first 256, except that they can not be used for insertion classes.'

and also

'The additional registers are realized as sparse arrays built from TEX’s 
main memory and are therefore less efficient.'

(Not sure if the later means in terms of speed or in terms of memory use.)
-- 
Joseph Wright