At 12:06 PM 1/5/99 +0000, you wrote:
>I hereby send version 0.2 of the ROBOTZ specification into the MSX world.
>1.2 Terminology, definitions and abbreviations
>----------------------------------------------
> <bit> 0 or 1, FALSE or TRUE
You mean FALSE = 0 and TRUE = 1?
> <byte> signed or unsigned 8-bit value
This vague "signed or unsigned" will cause trouble...
For example, is 0x80 bigger or smaller than 0x00?
If you see it as a signed number, 0x80 = 128 so 0x80 > 0.
But if you see it as an unsigned number, 0x80 = -128 so 0x80 < 0.
> <address> word in range $0000 - $3FFF (15 bit)
That's 14 bits...
> <flag> Z, P, N, NZ, NP, NN (bitmask over flags status reg)
If you use a bit mask, all nonzero values should be interpreted as "TRUE".
In your definition, only 1 was interpreted as "TRUE".
I think nowhere in the document is stated what the flag mean. I guess
"Zero, Positive, Negative, Non-Zero, Non-Positive, Non-Negative", is this
true?
> The machine has two stacks. One for calculations and parameter passing
> (a-stack) and one for storing return addresses for CALL instructions
> (c-stack). The a-stack is located in memory, the c-stack is machine-
> internal.
Why do you want the a-stack to be located in the virtual machine's memory?
That will only tempt people to mess with it.
> [META: Do I have to explain the notion of stack machine here?]
I don't think so. Although most people probably don't know what a stack
machine is, it isn't really important for the understanding of this document.
> [META: I need some input here. Should there be a fixed address range for
> the stacks?
If you put them in memory, yes. But I suggest you don't put them in memory,
in that case you only have to say something about their size.
> Could it be possible to intergrate the two stacks into one?
I think they can, but I need more time to think this through.
>2.2 Status Registers
>--------------------
> The registers are divided into two classes: public and private.
^^^^^^^^^
Please state "status registers" explicitly here (you do that in the rest of
the paragraph, but not in the first sentence).
>2.2.1 Private status registers
>
> [...]
>
> The next fields are only filled in when a robot is present on that
> position. They are a copy of the public status registers of that
> robot.
>
> env[][].alive - (byte)
> env[][].action - (byte)
If you swap paragraph 2.2.1 and 2.2.2, readers will see the description of
the public status registers first, so they can understand this information
(alive and action fields).
> Executing an action command (SCAN, MOVE etc) will decreae the value of
^^^^^^^
Typo...
> Syntax: SCAN
>
> The lower 3 bits of stacktop indicate in which direction the SCAN should
> be performed (X = robot, + = scanned area):
>
> 0 - north + + + + +
> . + + + .
> . . X . .
> . . . . .
> . . . . .
Is the scanner range 2 squares or is this just an example?
> Syntax: MOVE
>
> The lower 2 bits of stacktop indicate the direction in which the robot
> is moved:
> 0 - north
> 1 - east
> 2 - south
> 3 - west
Why not use the same encoding as used for scan?
Since diagonal moving as apparently not allowed, you could simply use bits
1 and 2 instead of 0, 1 and 2.
> Syntax: ATCK
>
> The ATCK command makes the robot attack another robot at a neighbouring
> square.
What if there is no robot in that square? Is the empty square attacked or
is there no attack at all? Since attacking costs a turn, there is a
difference.
> The lower 2 bits of stacktop indicate in which the attack is performed:
^
"direction"
> Syntax: DROP
>
> Drops the amount of energy indicated by the stacktop from the energy supply
> onto the field. When the value of the stacktop is 0 or negative, no energy
> will be dropped.
When is a "signed or unsigned" value negative?
> [META: I dropped the SKIP command, as the same effect can be achieved by
> PUSH 0 followed by DROP. Big advantage is that all action commands now
> have the same syntax and the same stack behaviour! And a command less
> further simplifies the machine, of course :-)]
Usually, I agree, but I'm not sure it's a good idea here.
If someone uses the "public.action" register to remember its previous
action, it's very confusing that doing nothing is also called "DROP".
>3.2.1 SKIP
>
> [...]
>
> [META: To be able to implement this properly, it would be easy if all
> commands have an equal length opcode, or if the length of the opcode
> is somewhere encoded in the opcode itself. Hm...]
Not necessarily. You could make a flag "execute", which is usually TRUE,
but turned off for the duration of one instruction by the SKIP command if
the skip flag is true.
In this way, you do fetch the instruction following the SKIP command, but
you don't execute it.
> The arithmatic operations take the two topmost elements of the a-stack
> perform the operation and push the result on the a-stack again. Flags
> will be set as expected.
What about stating "Flags will always be set according to the topmost stack
element."?
> ADD
> SUB
> MUL
> DIV
> MOD
>
> CP
Isn't "CP" equal to "SUB"?
Why isn't there a "NEG" operation?
Awaiting v0.3... ;)
Bye,
Maarten
****
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
****
