At 12:06 PM 1/5/99 +0000, you wrote:
>> <bit> 0 or 1, FALSE or TRUE
>
>You mean FALSE = 0 and TRUE = 1?
I should kill the "FALSE or TRUE" part here, I guess...
Actuallt, I'd like any non 0 value to be TRUE :-)
>> <byte> signed or unsigned 8-bit value
>
>This vague "signed or unsigned" will cause trouble...
Absolutely 'non 0' (eh.. TRUE, that is) :-)
The problem is that I don't know if it suffices to define only
signed values. (Only unsigned values definitely won't...)
>> <address> word in range $0000 - $3FFF (15 bit)
>
> That's 14 bits...
I meant $0000 - $7FFF, 15 bits, 32kB address space :-)
(Which is quite a lot, come to think of it, maybe I should limit it
to 14 bits/16kB)
>> <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".
Ok, as stated above, I'll change that...
> 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?
At the description of the flag register, the meaning of Z, N and P is
defined. NZ, NP and NN are not defined, that's 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.
True. I put it in memory because thew stack usualy _is_ in user space memory
(although there exist uPs with an internal stack...)
>> [META: I need some input here. Should there be a fixed address range for
>> the stacks?
>
> If you put them in memory, yes.
Another possibility is to introduce a few registers (read/write), which set
the stack ranges. In that case a user can define his own stack sizes and make
efficient use of the available memory...
>> But I suggest you don't put them in memory,
>> in that case you only have to say something about their size.
True. Any other arguments in favour of putting them outside memory, apart
from the possibility to mess with the stacks?
>> Could it be possible to intergrate the two stacks into one?
>
> I think they can, but I need more time to think this through.
Me too. At least till the wqeekend, when I can recover my lecture notes
on compiler building :-)
>>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).
Ah, ok.
> 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).
Hm, not a bad idea. I'll do that...
> Is the scanner range 2 squares or is this just an example?
It's an example. The scanner ranges upto the borders of the playing field.
I'll make that more clear. (Maybe that should come in the game description)
>> 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.
That's one sensible solution, another could be limiting the possibility
of the SCAN command such that it can only scan north, south east and west
and take the northwest etc out...
>> 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.
IMHO, the empty square should be attacked, regardless of whether the square
is actually occupied or not and it takes a turn. Question is whether you
will lose energy attacking an empty square...
A similar argument holds for the MOVE command of course. What should happen
if a robot wants to MOVE to an occupied square? IMHO, only the result of the
MOVE should be ignored: energy is lost, turn is over, but you did not move.
>> 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?
When the N flag is set :-)
>> [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".
Hm, ok. I didn't think about that. It will reappear in v0.3 as PASS,
as there's another command called SKIP!
>>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.
Again, a perfect idea :-)
>> 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."?
Ok. As I said: I didn't work out this secion of the document, yet...
> Isn't "CP" equal to "SUB"?
COm eto think of it, you're right (again :-))
> Why isn't there a "NEG" operation?
Oops! Lost in the bitbucket of Billy's Notepad...
> Awaiting v0.3... ;)
Duh.. with your comments being right all the time, wouldn't it be easier if
_you_ wrote the versions and _I_ be awaiting them? ;-D
Eric
****
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/)
****
