Virtual Machine question...
Mathew J Binkley
things do the TADS engine support that the Z-engine doesn't?
Mat
Stephen Granade
One of the big things that recent versions of the TADS 2 engine
support is the dynamic creation of objects. TADS does not have the
hard-coded memory limit that the z-machine has; you'd have to shoehorn
dynamic object creation into the z-machine.* There are some other
fiddly bits as well, enough to make the project, mmm, non-trivial.
Stephen
* Yes, you could work around it, but this likely falls into the "more
trouble than it's worth" category
--
Stephen Granade | Interested in adventure games?
sgra...@phy.duke.edu | Visit About Interactive Fiction
Duke University, Physics Dept | http://interactfiction.about.com
Ross Presser
>TADS does not have the
>hard-coded memory limit that the z-machine has; you'd have to shoehorn
>dynamic object creation into the z-machine.*
How about compiling TADS-2 to the glulx virtual machine?
--
Ross Presser * ross_p...@imtek.com
"A free-range shoggoth is a happy shoggoth, and a happy shoggoth is
generally less inclined to eat all of you at once." - Tim Morgan
Matthew Russotto
Ross Presser <rpre...@NOSPAMimtek.com.invalid> wrote:
>Stephen Granade <sgra...@phy.duke.edu> wrote:
>
>>TADS does not have the
>>hard-coded memory limit that the z-machine has; you'd have to shoehorn
>>dynamic object creation into the z-machine.*
>
>How about compiling TADS-2 to the glulx virtual machine?
The Glulx VM also has a hardcoded limit -- hardcoded in the game file.
You could make it quite large, if you could trust interpreters not to
allocate the memory until you touched it, which you can't. Besides,
what would be the advantage?
--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
Andrew Plotkin
> In article <Xns907170AD6...@209.155.56.97>,
> Ross Presser <rpre...@NOSPAMimtek.com.invalid> wrote:
>>Stephen Granade <sgra...@phy.duke.edu> wrote:
>>
>>>TADS does not have the
>>>hard-coded memory limit that the z-machine has; you'd have to shoehorn
>>>dynamic object creation into the z-machine.*
>>
>>How about compiling TADS-2 to the glulx virtual machine?
> The Glulx VM also has a hardcoded limit -- hardcoded in the game
> file.
There's an optional extension to allow the program to expand that
limit dynamically. The Glulxe interpreter supports this. I designed it
to handle exactly this kind of thing, more or less.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Gore won the undervotes:
http://www.gopbi.com/partners/pbpost/news/election2000_pbgore.html
David Given
Stephen Granade <sgra...@phy.duke.edu> writes:
[...]
> One of the big things that recent versions of the TADS 2 engine
> support is the dynamic creation of objects. TADS does not have the
> hard-coded memory limit that the z-machine has; you'd have to shoehorn
> dynamic object creation into the z-machine.* There are some other
> fiddly bits as well, enough to make the project, mmm, non-trivial.
...not to mention garbage collection.
> * Yes, you could work around it, but this likely falls into the "more
> trouble than it's worth" category
Actually converting the TADS byte-codes into Z-machine byte codes wouldn't
be too hard. However, you'd also need a run-time system; a dynamic memory
manager and a mark/sweep garbage collector would be the main things. Both
of these are repeatedly solved problems and are doable. Whether you could
run a useful game in the 64kB of RAM provided by the Z-machine is an
entirely different matter.
It ought to be possible for Glulx, though.
--
+- David Given --------McQ-+ "...thus there might be a great reduction in
| Work: d...@tao-group.com | useless expenditure on Nuclear rockets, reducing
| Play: d...@cowlark.com | inflation and stabilising the price of cat foods."
+- http://www.cowlark.com -+ --- UK pat. GB1426698
Matthew Russotto
Andrew Plotkin <erky...@eblong.com> wrote:
>Matthew Russotto <russ...@wanda.pond.com> wrote:
>> In article <Xns907170AD6...@209.155.56.97>,
>> Ross Presser <rpre...@NOSPAMimtek.com.invalid> wrote:
>>>Stephen Granade <sgra...@phy.duke.edu> wrote:
>>>
>>>>TADS does not have the
>>>>hard-coded memory limit that the z-machine has; you'd have to shoehorn
>>>>dynamic object creation into the z-machine.*
>>>
>>>How about compiling TADS-2 to the glulx virtual machine?
>
>> The Glulx VM also has a hardcoded limit -- hardcoded in the game
>> file.
>
>There's an optional extension to allow the program to expand that
>limit dynamically. The Glulxe interpreter supports this. I designed it
>to handle exactly this kind of thing, more or less.
Yeah, I just found it. Shame on me for only skimming the spec...
Kevin Forchione
news:99qmcp$1as$1...@news.panix.com...
> Matthew Russotto <russ...@wanda.pond.com> wrote:
> > In article <Xns907170AD6...@209.155.56.97>,
> > Ross Presser <rpre...@NOSPAMimtek.com.invalid> wrote:
> >>Stephen Granade <sgra...@phy.duke.edu> wrote:
> >>
> >>>TADS does not have the
> >>>hard-coded memory limit that the z-machine has; you'd have to shoehorn
> >>>dynamic object creation into the z-machine.*
> >>
> >>How about compiling TADS-2 to the glulx virtual machine?
>
> > The Glulx VM also has a hardcoded limit -- hardcoded in the game
> > file.
>
> There's an optional extension to allow the program to expand that
> limit dynamically. The Glulxe interpreter supports this. I designed it
> to handle exactly this kind of thing, more or less.
Perhaps it would be better to compile z-code to TADS-2 format.
--Kevin
Ross Presser
>In article <Xns907170AD6...@209.155.56.97>,
>Ross Presser <rpre...@NOSPAMimtek.com.invalid> wrote:
>>Stephen Granade <sgra...@phy.duke.edu> wrote:
>>
>>>TADS does not have the
>>>hard-coded memory limit that the z-machine has; you'd have to
>>>shoehorn dynamic object creation into the z-machine.*
>>
>>How about compiling TADS-2 to the glulx virtual machine?
>
>The Glulx VM also has a hardcoded limit -- hardcoded in the game
>file. You could make it quite large, if you could trust interpreters
>not to allocate the memory until you touched it, which you can't.
>Besides, what would be the advantage?
Port the interpreter to a new machine once, and twice as many authors
can write games you can play?
Sean T Barrett
>Perhaps it would be better to compile z-code to TADS-2 format.
I thought the problem people were considering was that of running
Tads-2 programs on machines that lack Tads-2 interpreters? Z-code
is already widely portable.
Either way, though, I think this sort of cross-porting would
be more useful if the target format were designed for portability.
Tads2 and Tads3 do not have clearly-defined VMs which support a
variety of implementations and a variety of source languages. For
an example of a high-level (as opposed to Zmachine or Glux) VM which does,
see my proposal for Slux at http://world.std.com/~buzzard/slux/slux.html
which I need to revise at some point to remove the 'set'
datatype.
Unfortunately, at this point in time there are exactly 0
compilers or interpreters that support Slux, but I think
it's much easier to implement an interpreter for and should
support retargetting from many languages, e.g. because it
supports definable inheritence rules.
Sean
Ross Presser
>Perhaps it would be better to compile z-code to TADS-2 format.
Well, my Hidden Agenda was to finally get TADS games to be able to run
on PalmOS. I know there's no glulx 'terp for PalmOS yet, but it seems
slightly more possible than a TADS-2 'terp.
Stephen Granade
> "Kevin Forchione" <Ke...@lysseus.com> wrote:
>
> >Perhaps it would be better to compile z-code to TADS-2 format.
>
> Well, my Hidden Agenda was to finally get TADS games to be able to run
> on PalmOS. I know there's no glulx 'terp for PalmOS yet, but it seems
> slightly more possible than a TADS-2 'terp.
It should be possible(*) to create a Palm interpreter for TADS
3. However, I suspect the growing power of PDAs will make such
hoop-jumping as compiling all languages to one VM less necessary.
Stephen
(*) By "should be possible" I mean "not strictly impossible, but still
quite a bit of work."
Mike Roberts
This would in theory be possible, but so far no one has been sufficiently
motivated to try.
First, there are some serious technical hurdles: the big ones are dynamic
memory allocation, dynamic string and list management, and the extensive
built-in command parsing system in tads 2. (Tads 3 would present an even
bigger challenge because of its automatic garbage collector and greater
reliance on dynamic memory management.) I think the z-machine is enough of
a general-purpose computer that all of these things could be implemented as
part of a run-time library implemented in z-code, but this extra code plus
the data structures required to represent all the dynamic data would eat up
a lot of z-machine memory, almost certainly placing unreasonable constraints
on the size of a tads game that could be run in such an environment.
Second, the practical benefits seem limited. There would be an element of
coolness to having a single universal interpreter, and the nostalgia value
of running modern games on the Infocom engine of lore is significant to a
lot of people, but in my opinion these aren't of great practical importance
(and I certainly don't mean to disparage the value anyone does place on
these - I know there are other things of value besides practical
considerations, and I know that not everyone shares my idea of what is and
isn't of practical importance). I think the main practical benefits would
be somewhat decreased porting work (one less interpreter to port); somewhat
increased portability, especially to handhelds; and the availability of the
z-terp user interfaces, for anyone who prefers those to the tads
equivalents. The first of these - decreased porting work - might be
non-trivial, but I don't think it's as big as it might at first appear: once
the tads interpreter has been ported to a platform, keeping it updated tends
to be pretty simple; it's already been ported to lots of platforms; and the
rate of creation of new platforms is small. Other considerations, such as
reducing the number of interpreters one must install, don't seem to get
anyone very exercised.
So, I think the amount of work to create a tads-to-z-machine cross-compiler
seem so large when compared with the potential benefits that no one has
taken it upon themselves to try it. I don't mean to dissuade you, though -
if you want to give it a try, I would be happy to offer any advice you
wanted about it.
--Mike
mjr underscore at hotmail dot com
John Colagioia
> (*) By "should be possible" I mean "not strictly impossible, but still
> quite a bit of work."
Heh...I thought the "official" term for that was "technically feasible, if
one really needed it."
Kevin Forchione
"John Colagioia" <JCola...@csi.com> wrote in message
news:3AC1F73F...@csi.com...
Actually the technical term is "interesting".
--Kevin
Stephen Granade
Andrew Plotkin
>> "John Colagioia" <JCola...@csi.com> wrote in message
>> news:3AC1F73F...@csi.com...
>> > Stephen Granade wrote:
>> >
>> > > (*) By "should be possible" I mean "not strictly impossible, but still
>> > > quite a bit of work."
>> >
>> > Heh...I thought the "official" term for that was "technically feasible, if
>> > one really needed it."
>>
>> Actually the technical term is "interesting".
> Or "non-trivial."
Around CMU, we say "neat idea".
Yeah, that's a... neat idea.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* My vote counts -- count my vote!
Larry Smith
>
> "Kevin Forchione" <Ke...@lysseus.com> writes:
>
> > "John Colagioia" <JCola...@csi.com> wrote in message
> > news:3AC1F73F...@csi.com...
> > > Stephen Granade wrote:
> > >
> > > > (*) By "should be possible" I mean "not strictly impossible, but still
> > > > quite a bit of work."
> > >
> > > Heh...I thought the "official" term for that was "technically feasible, if
> > > one really needed it."
> >
> > Actually the technical term is "interesting".
>
> Or "non-trivial."
SMOP
--
.-. .-. .---. .---. .-..-. | Do not mistake my cynicism
| |__ / | \| |-< | |-< > / | for dispair for deep inside
`----'`-^-'`-'`-'`-'`-' `-' | me is an optimist forever
http://www.smith-house.org/ | asking, "Why not?"
Jonadab the Unsightly One
> So, I think the amount of work to create a tads-to-z-machine cross-compiler
> seem so large when compared with the potential benefits that no one has
> taken it upon themselves to try it. I don't mean to dissuade you, though -
> if you want to give it a try, I would be happy to offer any advice you
> wanted about it.
IMO, a TADS-to-glulx cross-compiler makes more sense -- because
it cares for the upper-limit on size, if nothing else.
Not that I'm volunteering; if I had unlimited time, I'd finally
finish that game I've been designing since 1996.
- jonadab