1. CoreScript issues
- Posted by J E M <budmeister1 at JUNO.COM>
Aug 24, 1999
-
Last edited Aug 25, 1999
>I was thinking ICWS'88 compatability (as the first 'standard' standard
to
>support), but not getting there anytime soon... Y'know, something to do
down
>the line.. Anyway, 'fun' sounds good too. :)
I guess it's up to Rod, since it _is_ his code ;)
>I figured a graphical Llama version (once Llama is ready) would be cool,
as
>it'd be able to run on anything Llama can run on. Of course, it'll be a
>while until that happens... (It'd definetally be more user-friendly than
a
>command-line version that makes you want to code a shell like PSHELL for
it. :)
I haven't looked at Llama yet (sorry David), but from what I've been
reading
it sounds fantastic. That is definitly a direction we could take it after
the commandline version is done...
ewwww, I was hoping no one would mention pshell ;P
>>I just finished support for labels today. I'll post a copy when I test
>>it some more..
I sent a prototype version of CWC to Rod last night that includes support
for labels, among other things. I wanted to get a head start on coding
the
changes for his next version before it comes out ;)
Speaking of "coding changes before it comes out", I was at a Microsoft
seminar
today entitled 'Creating Dynamic Webpages with DHTML & IE5'. The
seminar's speaker
made a comment, in reference to emerging W3C standards on XML & CSS, that
I found a little funny:
"Microsoft is always the first to implement new Internet standards.
That is
how we keep one step ahead of the competition, for example IE5's
support for
XML, CSS1 & 2, and the DOM."
It seems to me that MS has taken _working_standards_ and extended them,
then
released their new version and tried to add the extensions to the
standards :)
In fact, the Document Object Model's (DOM) draft hasn't been finalized
yet
last I heard...
>I see some areas where that would help. It doesn't support it yet, I'm
going
>to look at some expression evaluators written in Euphoria.
well, it's just an idea. I don't know if it would have any significant
advantage to having just labels, but I thought I'd throw the idea out and
see
what happened ;)
David Cuny has an expression evaluator named eval.zip, and Andy
Montgomery
has an expression evaluator named parse.zip. Both are on the archives
page
(try looking under "Math").
--[Labels]--
>Basically, the first 'word' is the label if it isn't an instruction.
I considered doing it that way, but I found it easier to just have
labels use a colon at the end (obviously). To me, having labels use
a colon seemed to be more natural way of doing it, but my BASIC roots
could be showing ;)
One advantage to having labels end in a colon is for error checking.
If the first word isn't an instruction or label, then it's wrong.
If the first word is a label and the second isn't an instruction, then
it's wrong.
>I scan all the lines.
<snip>
Wow, we're totally separated, and yet coding as one mind. I wrote mine
almost identical to yours. Truly wierd :)
Mine isn't truly two pass, but close enough:
First pass: tokenize all the lines and strip blank lines.
Second pass: finds labels, adds them to a lookup table with their line
number,
and removes them from the line.
Third pass: interpret the opcodes and resolve any labels, return the
compiled
code to the calling routine.
The approach we took is the same, even though our code probably looks
different.
I'm seriously considering merging the first and second steps together,
but
we'll see (I'm waiting until I can remember why I did it that way :)
>I don't know if I should 'fix' this or not. :)
If you fix it, I gotta fix it too ;)
----->Buddy
budmeister1 at juno.com
2. Re: CoreScript issues
>I haven't looked at Llama yet (sorry David), but from what I've been
>reading
>it sounds fantastic. That is definitly a direction we could take it after
>the commandline version is done...
If it's ready to port, and Llama isn't ready yet (probably will be the
case), it could be ported to Win32lib, since there aren't many differences
(yet).
>>>I just finished support for labels today. I'll post a copy when I test
>>>it some more..
>
>I sent a prototype version of CWC to Rod last night that includes support
>for labels, among other things. I wanted to get a head start on coding
>the
>changes for his next version before it comes out ;)
I've been thinking about expressions. I'm going to add them before I release
the version I have. (Should be soon.)
>Speaking of "coding changes before it comes out", I was at a Microsoft
>seminar
>today entitled 'Creating Dynamic Webpages with DHTML & IE5'. The
>seminar's speaker
>made a comment, in reference to emerging W3C standards on XML & CSS, that
>I found a little funny:
>
> "Microsoft is always the first to implement new Internet standards.
>That is
> how we keep one step ahead of the competition, for example IE5's
>support for
> XML, CSS1 & 2, and the DOM."
>
>It seems to me that MS has taken _working_standards_ and extended them,
>then
>released their new version and tried to add the extensions to the
>standards :)
>In fact, the Document Object Model's (DOM) draft hasn't been finalized
>yet
>last I heard...
Basically, "We stay on top of the compitetion by creating the standards they
don't support."... :)
(I want my replacement SideWinder Precision Pro joystick to come.. it's over
a week overdue... It's a great stick.)
>well, it's just an idea. I don't know if it would have any significant
>advantage to having just labels, but I thought I'd throw the idea out and
>see
>what happened ;)
I had already been thinking about them while I was doing labels. There are
some areas in my warriors that expressions would make it a bit easier.
>David Cuny has an expression evaluator named eval.zip, and Andy
>Montgomery
>has an expression evaluator named parse.zip. Both are on the archives
>page
>(try looking under "Math").
I've downloaded one from the Recent User Contributions, but it has too many
features... It's better than the rest as far as the features I want to use.
I'll need to strip it down some, though.
>
>--[Labels]--
>
>>Basically, the first 'word' is the label if it isn't an instruction.
>
>I considered doing it that way, but I found it easier to just have
>labels use a colon at the end (obviously). To me, having labels use
>a colon seemed to be more natural way of doing it, but my BASIC roots
>could be showing ;)
Agh! Code written for mine won't work on yours (without colons), and code
written on yours WILL work on mine... Making up some standards eh? ;) (Just
kidding around. :)
>One advantage to having labels end in a colon is for error checking.
>If the first word isn't an instruction or label, then it's wrong.
>If the first word is a label and the second isn't an instruction, then
>it's wrong.
Actually, from reading some files on pMARS, here is the basic idea for
pMARS' parser:
Read in the file
First pass: Find labels
Second pass: Evaluate labels and syntax check
Look familiar? :)
Also, it appears (I haven't tested yet), that ALL labels in front of an
instruciton are added, in other words:
so much for clear code: MOV bomb, @bomb
JMP so
JMP much
JMP for
JMP clear
JMP code
All of those JMP instructions would jump to that first line. I might modify
my parser to do that. Why? I dunno...
>>I scan all the lines.
><snip>
>
>Wow, we're totally separated, and yet coding as one mind. I wrote mine
>almost identical to yours. Truly wierd :)
And it looks like we're not the only ones.
>Mine isn't truly two pass, but close enough:
>
>First pass: tokenize all the lines and strip blank lines.
>Second pass: finds labels, adds them to a lookup table with their line
>number,
> and removes them from the line.
>Third pass: interpret the opcodes and resolve any labels, return the
>compiled
> code to the calling routine.
I do what you do in the first and second passes in the first pass. (After
the lines are broken into each 'word', I check for the labels.)
>The approach we took is the same, even though our code probably looks
>different.
>I'm seriously considering merging the first and second steps together,
>but
>we'll see (I'm waiting until I can remember why I did it that way :)
That's simple: If you combined passes two and three, then this code wouldn't
work:
start MOV bomb, @bomb
ADD #4, bomb
JMP start
bomb DAT #0
Why? Because on the first line, 'bomb' hasn't been added to the label list
yet. But when you do the pass through all the code and get the labels before
you handle the label referneces, it works.
3. Re: CoreScript issues
Robert Pilkington wrote:
> If it's ready to port, and Llama isn't ready yet
> (probably will be the case), it could be ported
> to Win32lib, since there aren't many differences
> (yet).
This is the best plan. Work on GtkLib seems to indicate that, other than the
Llama syntax of:
connect( control, "signal", routine_id )
instead the Win32Lib syntax of:
signal[control] = routine_id
the library calls to Win32Lib/GtkLib/Llama should be pretty much identical.
-- David Cuny
4. Re: CoreScript issues
>If it's ready to port, and Llama isn't ready yet (probably will be the
>case), it could be ported to Win32lib, since there aren't many
differences
>(yet).
Is anyone interested in porting it to Win32lib? I know Martin mentioned
maybe adding a graphical display, but can that be done with a GUI?
>I've been thinking about expressions. I'm going to add them before I
release
>the version I have. (Should be soon.)
>There are some areas in my warriors that expressions would make it a bit
easier.
As in any language, things always look easier using a feature that's not
implemented yet :) It's like wanting all sorts of new opcodes like CMP,
SLT, SEQ,
etc. Instead of thinking of what you *could* do if you had those, try
thinking of
what you *can* do with what you have... IMHO ;)
There doesn't seem to be an immediate need for them, so I think I'll hold
off until the next version comes around...
>I've downloaded one from the Recent User Contributions, but it has too
many
>features...
It might be easier writing a small-scale version yourself :)
>Agh! Code written for mine won't work on yours (without colons), and
code
>written on yours WILL work on mine... Making up some standards eh? ;)
Ironic how that worked out...
Yeah, Bill Gate$ has been giving me some pointers ;)
>Read in the file
>First pass: Find labels
>Second pass: Evaluate labels and syntax check
>Look familiar? :)
Wow... I must have subconsciously been coding according to the standard
and
not even realized it!
----->Buddy
budmeister1 at juno.com
5. Re: CoreScript issues
> >If it's ready to port, and Llama isn't ready yet (probably will be the
> >case), it could be ported to Win32lib, since there aren't many
> differences
> >(yet).
>
> Is anyone interested in porting it to Win32lib? I know Martin mentioned
> maybe adding a graphical display, but can that be done with a GUI?
It should be possible. Win32Lib comes with a demo of a Defender type game.
Probably shouldn't worry about porting it until after the DOS version is
mostly complete, though.
> >I've been thinking about expressions. I'm going to add them before I
> release
> >the version I have. (Should be soon.)
> >There are some areas in my warriors that expressions would make it a bit
> easier.
>
> As in any language, things always look easier using a feature that's not
> implemented yet :) It's like wanting all sorts of new opcodes like CMP,
> SLT, SEQ,
> etc. Instead of thinking of what you *could* do if you had those, try
> thinking of
> what you *can* do with what you have... IMHO ;)
I'd do that, it's just that I've already done what I can. They're called
Strike and Assault. :) (Ok, there's probably ways to defeat both of them
every time, but I haven't found it yet. :)
> >I've downloaded one from the Recent User Contributions, but it has too
> many
> >features...
>
> It might be easier writing a small-scale version yourself :)
Yeah, but stripping another one down would result in less bugs, since the
code has already been debugged... Oh, nevermind. Before I even read your
message I had already built a mostly bug-free expression evaluator from
scratch. 
> >Read in the file
> >First pass: Find labels
> >Second pass: Evaluate labels and syntax check
> >Look familiar? :)
>
> Wow... I must have subconsciously been coding according to the standard
> and not even realized it!
Probably because the above is the most logical way to go about it..
Anyway, for the expressions, I have an evaluator written. I need to do some
more testing for it, but it appears stable now. It supports all the operands
that ICWS'94 supports. That is, +, -, *, /, and %. (Not many, IOW.)
There are some interresting things that happen if you use expressions that
aren't valid...
5 (-3) is read as 5 - 3
5 (5) is read as 5.
But everything else seems ok. (All correct expressions are evaluated
properly, and *, /, and % are performed before + and -.) I need to do some
more testing for crashes. If everything works, I should be able to release
the code in a couple days (at most).
