On Wed, Feb 23, 2005 at 03:02:32PM +0100, Leopold Toetsch wrote:
> I've here some small parts of a Z machine code translator. It runs not
> much more then a hello-worldish program.
>
> * written in PIR, using objects
> * translates Z code files to PIR
> * ~ 10 opcodes
I've here some small parts of a Z machine code translator. It runs not
much more then a hello-worldish program.
* written in PIR, using objects
* translates Z code files to PIR
* ~ 10 opcodes done
* objects, props, attributes, abbrevs are all missing
I've no time to play with it furth
anyway. (OK, I'm really hoping that's not
true, but we'll see.)
> Then let's think of some other solutions to the problem. This will
be
> pretty abstract, mind you.
Right. I should probably explain a bit about Z-code, because saving the
stack in Z is way easier (I think)
Luke Palmer <[EMAIL PROTECTED]> wrote:
> Maybe continuations aren't so hard to serialize after all (well,
> excluding things like open filehandles and such). What's the status on
> the serialization subsystem?
*nobody* did answer my summary of different schemes.
> Luke
leo
Amir Karger writes:
> Still working on the prelude to the preface to the "Z-machine running
> natively on Parrot" project, namely translating Z-code into a Perl
> executable. (My brother, who's a CS professor so he should know, says
> I'm actually *compili
Still working on the prelude to the preface to the "Z-machine running
natively on Parrot" project, namely translating Z-code into a Perl
executable. (My brother, who's a CS professor so he should know, says
I'm actually *compiling* it. Compiling bytecode to an interpreted
l
est it?!
Actually, I posted to rec.arts.int-fiction today to see if there are
any Z-machine regression tests lying around.
> I think that if you're comfortable writing it in perl, you should
> write
> one in perl first. It's a prototype. You can use it to learn how to
> d
On Mon, Sep 08, 2003 at 08:48:07PM -0700, Amir Karger wrote:
> Sure we can, and it's a tool we might want. I had gotten the impression
> that Dan considered having any extra scripts to be cheating. Then
> again,
> maybe cheating isn't such a bad thing, if it helps get the project
> started.
Cheat
> "AK" == Amir Karger <[EMAIL PROTECTED]> writes:
AK> --- Uri Guttman <[EMAIL PROTECTED]> wrote:
>> > "AK" == Amir Karger <[EMAIL PROTECTED]> writes:
>>
>> the designs range from a total code conversion, load and translate
>> the zcode into equivilent imcc. this should be the e
> "AK" == Amir Karger <[EMAIL PROTECTED]> writes:
AK> So you mean you require the first byte to be a number <=8, and the
AK> pointer to the end of the dictionary has to be less than the size
AK> of the file, the flag bits need to have sane values, etc.?
AK> Interesting. I guess with so
--- Uri Guttman <[EMAIL PROTECTED]> wrote:
> > "AK" == Amir Karger <[EMAIL PROTECTED]> writes:
>
> the designs range from a
> total code conversion, load and translate the zcode into equivilent
> imcc. this should be the easiest to do as you just need to write a
> code
> generator for each zco
--- Uri Guttman <[EMAIL PROTECTED]> wrote:
> > "AK" == Amir Karger <[EMAIL PROTECTED]> writes:
>
> AK> Er, I'll assume you have a magic (pun slightly intended) way to
> AK> decide which files are Zcode? How will you tell the Zcode
> AK> from other bytecode noise? I don't see anything pa
3, Amir Karger wrote:
> I'll need to write Zmachine.ops, or some such. It will include all
> the Z-machine operations, which the bytecode will call.
Yep.
OK. Although Luke Palmer seems to think differently.
That's OK--there are a number of different ways to go about this.
He s
> "AK" == Amir Karger <[EMAIL PROTECTED]> writes:
AK> Er, I'll assume you have a magic (pun slightly intended) way to
AK> decide which files are Zcode? I mean, sure, if the rule is
AK> "anything that doesn't match a Parrot header", you're fine, but
AK> once you've included Python bytec
i <[EMAIL PROTECTED]> wrote:
> On Sat, 6 Sep 2003, Amir Karger wrote:
>
> > I'll need to write Zmachine.ops, or some such. It will include all
> > the Z-machine operations, which the bytecode will call.
>
> Yep.
OK. Although Luke Palmer seems to think differentl
; it's extremely hard?
> >
> > We'd need dynamic opcode loading because we don't want to have the
> > Z-machine specific opcodes compiled into every parrot (or every other
> > specialist set of opcodes)
>
> Right. What you're saying here is that I&
On Mon, 8 Sep 2003, Piers Cawley wrote:
> Luke Palmer <[EMAIL PROTECTED]> writes:
> > Zellyn Hunter writes:
> >> So I take it the goal is to to teach parrot to understand z-machine
> >> opcodes, rather than simply writing a z-machine interpreter that
> >&
Luke Palmer <[EMAIL PROTECTED]> writes:
> Zellyn Hunter writes:
>> So I take it the goal is to to teach parrot to understand z-machine
>> opcodes, rather than simply writing a z-machine interpreter that
>> runs on parrot, or rewriting inform to compile to parrot?
&
ading because we don't want to have the
> Z-machine specific opcodes compiled into every parrot (or every other
> specialist set of opcodes)
Right. What you're saying here is that I'll need to write Zmachine.ops,
or some such. It will include all the Z-machine operations,
icense stuff out of the way so I can get to actual
coding!
-Amir
p.s. re the email subject: For now, I'm calling the Parrot Z-machine
project "parrotZ". It's simple, it expresses that it's Z-machine in
Parrot, and it even rhymes with "frotz" if you pronounce it r
On Wed, 3 Sep 2003, Bernhard Schmalhofer wrote:
> Amir Karger wrote:
> > A couple more questions on the coding front:
> >
> > (2) WinFrotz, one of the popular C Z-machine runtimes, is GPL. If I
> > steal code or ideas from there, does Parrot or this piece of it have to
Amir Karger <[EMAIL PROTECTED]> wrote:
> A couple more questions on the coding front:
> (1) Even though it's supposed to be "native" Parrot support, I'm still
> allowed to write in PIR, right? Because that'll be translated to pasm
> and thereby be native.
You should target PIR. PIR is "native" pa
Amir Karger wrote:
A couple more questions on the coding front:
(2) WinFrotz, one of the popular C Z-machine runtimes, is GPL. If I
steal code or ideas from there, does Parrot or this piece of it have to
be GPL only instead of GPL/Artistic? I am happily ignorant about
licensing issues.
Hi,
I
e that'll be translated to pasm
> > and thereby be native.
> >
> > (2) WinFrotz, one of the popular C Z-machine runtimes, is GPL. If I
> > steal code or ideas from there, does Parrot or this piece of it have to
> > be GPL only instead of GPL/Artistic? I am happ
reby be native.
>
> (2) WinFrotz, one of the popular C Z-machine runtimes, is GPL. If I
> steal code or ideas from there, does Parrot or this piece of it have to
> be GPL only instead of GPL/Artistic? I am happily ignorant about
> licensing issues.
So I take it the goal is to to tea
Amir Karger <[EMAIL PROTECTED]> wrote:
> I got my fifteen bytes of fame in the P6 summary ...
Geewhillikins ... But you can always get more: Convert it into
Unicode (~:
_VL_
"But how can we do it if we don't know what it is?"
"Why, blame it all, we've GO
A couple more questions on the coding front:
(1) Even though it's supposed to be "native" Parrot support, I'm still
allowed to write in PIR, right? Because that'll be translated to pasm
and thereby be native.
(2) WinFrotz, one of the popular C Z-machine runtimes, is GPL.
m without having all this working, and when I've finished a large
part of the job, one of the core Parroters will be inspired to hack
up #s 1 and 2 overnight while at some YAPC instead of sleeping or
drinking beer.
> We'd need dynamic opcode loading because we don't want to have t
ob, one of the core Parroters will be inspired to hack
up #s 1 and 2 overnight while at some YAPC instead of sleeping or
drinking beer.
> We'd need dynamic opcode loading because we don't want to have the
> Z-machine specific opcodes compiled into every parrot (or every
ot
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> 2: dynamic bytecode conversion
> (This is the point where someone tells me that dynamic opcode loading now
> works)
No it doesn't. Albeit I have posted a proof of concept standalone
program months ago.
> Nicholas Clark
leo
meone tells me that dynamic opcode loading now
works)
We'd need dynamic opcode loading because we don't want to have the
Z-machine specific opcodes compiled into every parrot (or every other
specialist set of opcodes)
We'd want dynamic bytecode conversion because we want parrot to b
Hi. Hugely newbie at Parroting, but think it's the coolest.
So I was bummed to see that Befunge and BASIC had already been
parroted. (And Clinton Pierce even ported QuickBasic, which makes my
Language::Basic completely useless. Argh!) Then I thought, "What about
Z-machine?!" I w
32 matches
Mail list logo
