Newsgroups: perl.perl6.internals
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.perl.org
Return-Path: <l...@toetsch.at>
Mailing-List: contact perl6-internals-h...@perl.org; run by ezmlm
Delivered-To: mailing list perl6-intern...@perl.org
X-nextra-mail02-rcpt: <perl6-intern...@perl.org>
Message-ID: <3D7DC62D.8030500@toetsch.at>
Date: Tue, 10 Sep 2002 12:15:09 +0200
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011129
X-Accept-Language: en-us
MIME-Version: 1.0
To: P6I <perl6-intern...@perl.org>
Subject: Howto packout _SC / _NC KEYs
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-SMTPD: qpsmtpd/0.10, http://develooper.com/code/qpsmtpd/
Approved: n...@nntp.perl.org
From: l...@toetsch.at (Leopold Toetsch)
Lines: 40

imcc (0.0.9) has an integrated parrot interpreter and tries to write out 
  a PBC file too. Running code succeeds currently for ~95 % of perl6 
tests (in half the time ;-).

But I've problems in writing out the .pbc, especially Const_Table, type 
PFC_KEY / PARROT_ARG_SC (and _NC if one would use these).

The problem seems to be, that all other key types can be looked up by 
key.cache->int_val, but not _SC and _NC as there value is the contents 
of another string or number constant.

So packing a packfile seems not to be reversible.

I see currently 3 possible ways to workaround this problem:

1) make another indirection in reading an _SC or _NC key, so that
   key.cache->int_val is the index into the constant table and not the
   string_val or the num_val itself.

2) don't use ->data as the key->next pointer but some structure
    data -> { int idx, PMC *next } and store the constant index there.

3)
The easierst solution (for me): provide the possibility to call a 
callback, that fills the packed structure with the required data. 
Actually I have also this packed data, because on building the keys I 
assemble this packed data, which on PackFile_Constant_unpack_key() 
generates all the PMCs for runtime.

1) and 2) would be a general solution but require a major rewrite of key 
functions / access and have drawback for speed / memory usage.

3) is "if you want to packout _SC keys, do it yourself" ;-)

Comments welcome,
leo