New release of Git 1.2.2 (Glulx interpreter)
David Kinder
now available from the Archive:
http://www.ifarchive.org/indexes/if-archiveXprogrammingXglulxXinterpretersXgit.html
This is a new version from Iain. The change from 1.2.1 is the addition of a
patch from me to add support for the new Glulx 3.1 opcodes @malloc and
@mfree, which Inform 7 makes use of for indexed text. As a result, there
should be no Glulx features used by Inform 7 games that Git does not support.
Much of the credit for the new opcode support should go to Zarf, as I have
shamelessly stolen the heap implementation from Glulxe. However, if you come
across any problems with this, it's probably best to hassle me first :)
A new Windows build of 1.2.2 is available from the same location on the
Archive. This has also been compiled with GCC 2.95, allowing Git's "direct
threading" mode to be used, which gives a ~15% speedup over previous Windows
builds.
David
jeremydb
> A new release of Iain Merrick's very fast Glulx interpreter, Git 1.2.2, is
> now available from the Archive:
>
>
> This is a new version from Iain. The change from 1.2.1 is the addition of a
> patch from me to add support for the new Glulx 3.1 opcodes @malloc and
> @mfree, which Inform 7 makes use of for indexed text. As a result, there
> should be no Glulx features used by Inform 7 games that Git does not support.
>
> Much of the credit for the new opcode support should go to Zarf, as I have
> shamelessly stolen the heap implementation from Glulxe. However, if you come
> across any problems with this, it's probably best to hassle me first :)
>
> A new Windows build of 1.2.2 is available from the same location on the
> Archive. This has also been compiled with GCC 2.95, allowing Git's "direct
> threading" mode to be used, which gives a ~15% speedup over previous Windows
> builds.
>
> David
This is great news. Thank you!
jb
Kritsada Piriyakitpaiboon
> A new release of Iain Merrick's very fast Glulx interpreter, Git 1.2.2, is
> now available from the Archive:
>
>
> This is a new version from Iain. The change from 1.2.1 is the addition of a
> patch from me to add support for the new Glulx 3.1 opcodes @malloc and
> @mfree, which Inform 7 makes use of for indexed text. As a result, there
> should be no Glulx features used by Inform 7 games that Git does not support.
>
> Much of the credit for the new opcode support should go to Zarf, as I have
> shamelessly stolen the heap implementation from Glulxe. However, if you come
> across any problems with this, it's probably best to hassle me first :)
>
> A new Windows build of 1.2.2 is available from the same location on the
> Archive. This has also been compiled with GCC 2.95, allowing Git's "direct
> threading" mode to be used, which gives a ~15% speedup over previous Windows
> builds.
>
> David
You are super, David. You are the IF plumber fixing small leaks, here
and there, polishing the IF experience for everyone and that is a very
important role because most users will not be tolerant of any kind of
annoyance during play.
Kritsada Piriyakitpaiboon
David Kinder
I like that :-)
David
Ben Cressey
> Archive. This has also been compiled with GCC 2.95, allowing Git's "direct
> threading" mode to be used, which gives a ~15% speedup over previous Windows
> builds.
FWIW, GCC 4.2 also compiles Git with "direct threading" mode enabled.
Thanks for the patch! This will make Gargoyle users happy as well.
David Kinder
> FWIW, GCC 4.2 also compiles Git with "direct threading" mode enabled.
I got it to work with GCC 4.3, too. The resulting executable was
substantially (about 10%) slower than that produced with GCC 2.95, though.
David
Ben Cressey
> substantially (about 10%) slower than that produced with GCC 2.95, though.
What do you use to benchmark the speeds? I've just been loading up
the latest release of Alabaster and estimating the initial load time,
so anything more sophisticated would be an improvement on my technique.
jeremydb
Zarf has a memory heap test for @malloc and @mfree, but I'd like to do
some additional testing with @setmemsize to make sure that everything
is up and running properly in my interp.
Thanks a lot -
Jeremy
David Kinder
> What do you use to benchmark the speeds? I've just been loading up
> the latest release of Alabaster and estimating the initial load time,
> so anything more sophisticated would be an improvement on my technique.
I'm not using anything much more sophisticated - I have a hacked version of
my Glk library that will run through a text file of commands then print the
time taken from start-up to shut-down, and I ran that on play throughs of
Alabaster and Eric Eve's Nightfall.
David
David Kinder
I don't think there are any substantial game files in existence that use it
- I just wrote a very simple test that called the opcode directly, using
Inform as an assembler.
If you're testing an interpreter, I'd also suggest, if you haven't already
done so, saving from Zarf's memtest game running in Glulxe and Git, and then
trying to restore that in your interpreter, as well as vice versa.
David
jeremydb
deal with @setmemsize and got some testing underway. I'll check the
save and restore code compatibility between Glulx and Git, but I don't
expect any big surprises there.
So, I guess there'll be a new version of CellarDoor for all you Palm
IFers before too long... :)
Thanks again -
jb
vaporware
This uses setmemsize, as well as a couple other opcodes that are
rarely used in Inform games: http://hansprestige.com/snack/g/atc.ulx
Last I checked, it worked on Glulxe but failed on Git. I assume that's
because of a bug in the game, but I suppose it could be a bug in Git,
so it'd be interesting to see how it works in your interpreter. (I've
made no progress in tracking down the bug; the Glulx Snack library is
a nightmarishly massive pile of assembly code.)
vw
David Kinder
> This uses setmemsize, as well as a couple other opcodes that are
> rarely used in Inform games: http://hansprestige.com/snack/g/atc.ulx
>
> Last I checked, it worked on Glulxe but failed on Git. I assume that's
> because of a bug in the game, but I suppose it could be a bug in Git,
> so it'd be interesting to see how it works in your interpreter. (I've
> made no progress in tracking down the bug; the Glulx Snack library is
> a nightmarishly massive pile of assembly code.)
Coincidentally, I've been looking into this over the last few days - it's
looking like a bug somewhere in Git, but I'm still working on tracking it down.
David
d.ki...@btinternet.com
> Last I checked, it worked on Glulxe but failed on Git. I assume that's
> because of a bug in the game, but I suppose it could be a bug in Git,
> so it'd be interesting to see how it works in your interpreter.
It's a bug in the game, in the end. At some point the game makes the
call
@random 0
According to the spec, this returns a number anywhere in the full 32-
bit range, but atc.ulx gets upset if the value is large and negative,
with resulting invalid memory accesses. Git tries harder than Glulxe
to return random numbers covering all of this range. I can get the
same crash out of Glulxe if I change its random number generation
logic to match that of Git's, like so:
case op_random:
vals0 = inst.value[0];
if (vals0 == 0)
value = (glulx_random() & 0xffff) | (glulx_random() <<
16);
David
vaporware
Thanks, that was just what I needed. Here's a fixed version:
http://hansprestige.com/snack/g/atc.ulx
Source (unchanged): http://hansprestige.com/snack/g/atc.sn
Assembly listing: http://hansprestige.com/snack/g/atc.ula.zip
vw
Dave Griffith
> A new release of Iain Merrick's very fast Glulx interpreter, Git 1.2.2, is
> now available from the Archive:
This presents a name collision between this interpreter and the
source-code organizing program of the same name. Could we consider a
name change? Perhaps "gin" or "glin"?
--
David Griffith
dgr...@cs.csbuak.edu <-- Switch the 'b' and 'u'
Peter Pears
> In rec.arts.int-fiction David Kinder <da...@david.david> wrote:
>
> > A new release of Iain Merrick's very fast Glulx interpreter, Git 1.2.2, is
> > now available from the Archive:
>
> This presents a name collision between this interpreter and the
> source-code organizing program of the same name. Could we consider a
> name change? Perhaps "gin" or "glin"?
>
> --
> David Griffith
I am in no way affiliated or connected with either Git, and thought I
should make it clear before my post - I speak for no one but myself
(nice and redundant, just the way I like it).
According to http://git.kernel.org/?p=git/git.git;a=tags, the source-
code organizing program dates from two years ago. If this information
is incorrect, then the program should make the information easier to
find.
According to http://diden.net/if/git/releases/, the interpreter dates
from October 2003.
Apparently the interpreter is older, and if anyone has to change names
is the source-code organizing program.
That said, I see no reason why they shouldn't both have the same name.
Check out http://www.audacity.com/ for an example of a name clash that
was fully taken in stride. People who want the source-code program
will get to it, and people who want the interpreter will find it. We
should all be living in peace, harmony and weed.
vaporware
> In rec.arts.int-fiction David Kinder <da...@david.david> wrote:
>
> > A new release of Iain Merrick's very fast Glulx interpreter, Git 1.2.2, is
> > now available from the Archive:
>
> This presents a name collision between this interpreter and the
> source-code organizing program of the same name. Could we consider a
> name change? Perhaps "gin" or "glin"?
To paraphrase a classic movie, why should the Glulx interpreter change
its name? The source control system is the one that sucks.
vw
Otto Grimwald
> To paraphrase a classic movie, why should the Glulx interpreter change
> its name? The source control system is the one that sucks.
>
maybe because one is famous, the other one is not? ;)
Personnally I don't care, but I think it's generally not a so good idea
to have a project with a 3 letters name.