Hi!
> Hard-wireing the robot location to (2,2) is not flexible. If you would allow
> negative indices, you could place the robot at (0,0) and expand the scanner
> range with a lot less problems.
Placing the robot at (2,2) was indeed an attempt to avoid negative indices.
Putting the robot back to (0,0) is not much of a problem :-)
>> env[0..4][0..4] - the environment
>
> You could also use a part of the memory for this task. That would simplify
> the virtual machine.
The problem I had with putting the environment in memory, was that you
end up with two types of 'status': the status registers at one hand and
the environment in memory at the other hand. With the env in registers,
the complete robot machine state is in register and independent of the
memory. Also, there's less possibility of overwriting the env by accident
in this way...
> I'd like a 16-bit signed type as well ("integer" or "int").
Maybe my notation was a bit unclear (hey, it was a very first preliminary
pre-alpha 0.0 version!! ;-)), but with (un)signed I meant that both signed
and unsigned types exist.
> Is the stack automatically cleared every turn?
> I think that would be a good thing.
No! The stack must remain intact! A program could e.g. have a function
(subroutine) that performs a few scans (cost a turn each!) and then
give as result (on the stack!) the direction in which the robot should go.
> Why two variants of every action command? Isn't it easier to use the byte
> at the top of the stack?
Hm, come to think of it. Not a bad idea at all. As I said before:
Let's keep it simple! :-)
> And what does the byte mean anyway?
Ehm... in case of SCAN; the direction in which should be scanned, in case
of MOVE and ATCK the direction in which should be moved/attacked.
> Syntax:
> SKIP <flag>
> Semantics:
> Skips the execution of the next instruction if the flag is TRUE.
> Example:
> SKIP Z
> JP <address>
> is equivalent to
> JP NZ,<address>
Perfect!
> Does CALL store an address on top of the stack, or is the stack only used
> for arithmetic? If the stack is used for return addresses, it would be very
> difficult to pass parameters to a subroutine. Please think about this!
I was thinking of using another, machine internal, stack for return addresses
with exactly the possibility to pass parameters on the stack. Maybe I could
include a mechanism to perform indexed access to the stack, to make accessing
parameters easier. (I really have to dig up my lecture notes on compilers
again :-))
> I think you should specify how PUSB stores the byte in a word. People are
> bound to use this, so you'd better standardize it.
The idea was to store the byte in the LSB of the word (of course :-))
>> PUSH (<address>) push word at address <address> on stack
>
> Why doesn't PUSB (<address>) exist?
Ehh... because I forgot to put it in :-)
>>CLR clear the stack (dangerous! :-))
>
> Why is this instruction needed?
I don't know if it is needed. Actually, I think I'd better leave it out...
> Please include "MOD" as well.
> And define it such that "-1 MOD 3 = 2", not "-1 MOD 3 = 1" like Pascal.
Ok.
[logical ops]
> Are these only defined for booleans, or are bitwise operations on words
> supported as well?
I haven't thought about that, yet. I personally don't use the bitwise
operations a lot, but I guess they could come in handy, at some time...
> Actually, you don't need load instructions at all. Using the PUSH and POP
> operations, you can do anything a load instruction can do.
True. I'll get rid of them in the next version.
> Maybe some of you think "such a simplified virtual machine is not easy to
> program". That's true. But it's very easy to interpret, and it's also easy
> to make a compiler that compiles to such a virtual machine. So you don't
> have to program in the virtual machine language, but you can use a higher
> level language instead.
That was exactly what I had in mind :-)
> Keep up the good work! (please make v0.1 soon)
Thanks. I will! Most of the unclarity in the 0.0 version was to my eager
to give it out to the people. Besides, it's easier to embed comments (and
extract faults and other bugs!) in earlier stages of development...
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/)
****
