Hi,
> Add that signed numbers are stored in two's complement format.
Agree. Consider it done.
> Have you looked yet at the possibility of integrating the two stacks?
Yes. But only after I put version 0.3 online :-) To integrate the two stacks
is not that difficult, but it complicates stackhandling a little. Apart from
the normal stackpointer, there's an additional pointer, which I will call
RAP (return address pointer). When a CALL is executed, first, the RETurn
address for the CALL is pushed on the stack _and_ the current value of the
RAP. Then, the RAP gets the current value of the stack pointer. The RET
resets the value of the stack pointer to the value of the RAP; then the new
RAP value and the return address are popped from the stack.
In this way you create within the stack a linked list of (return address, next
pointer) pairs, which are separated by 'local' stack data.
> What about defining an "out of range" code? Every square out of scanner range
> will have that property when scanned.
> Advantages:
> - you know what to return when for example env[3][3] is requested
> - rules like "damaged robots will have reduced scanner range" can easily be
added later
Hm, I'll think about it :-)
> After a robot drops energy, it's possible for a robot and an energy supply to
> occupy the same square.
Hm, that means that the env[][] as it was wouldn't function anyway -
I'll redesign that part...
>> scan.n_supplies - (byte)
>
> Maybe it's better to report the amount of energy (sum) instead of the number
> of supplies?
That's also a possiblity. I'd say that if you look at an energy supply at
a long distance it's easier to decide _whether_ it is there, than to figure
out the size of it. That's in favour of the .n_supplies variant. On the other
hand, When the total amount of energy is returned, it's easier to make a move
in the right direction (just try to get the largest power supply :-))
> I think the scanner should have limited range, although it should be a lot
> larger than the range of the env variable.
Well, then make a proposal :-) How large should it be? Another, related
question: how large should we make the playing field? Maximum would be
32.768 x 32.768 squares (signed 16-bit word maximum value), but I guess
that's a little too large :-)
> [META: Would it be more fun to define a scanner that only scans in a line?
> so: scanning e.g east would be defined as:
>. . . . . .
>. . . . . .
>. X + + + +
>. . . . . .
>. . . . . .
> ]
No, that would make the scanner too limited.
>> Syntax: SKIP
>> Opcode: %0001ifpz
>>
>> ...
>>
>> mask | name
>> I F P Z |
>> +---
>> 0 0 0 0 | -(not used - will never jump)
>
>This is the "NOP" for the abstract robot machine!
Right, but has another opcode. I could redefine the opcode, so it has opcode
$00 of course :-)
>(Don't say "not used", let people decide what they want to use and what not.)
Ehm, If I define that $10 is an illegal instruction, then it's not used :-)
>> 1 0 0 0 | -(not used - will always jump)
>
>This is a useful instruction: it allows you to jump over the next instruction.
>Since a SKIP requires less bytes than a JUMP, the compiler can use it to
>optimize the code.
Ok, I'll scrap the words "not used", here...
>What if you changed "negative/positive" into "sign/no sign (S/NS)"?
>In that case, you could make "SKIP" mean "skip always" and "SKIP N" mean "skip
>never (NOP)".
>By the way, I really like the idea of "opcode made of truth table".
Me too :-) I just got the idea from the z80 LD instructions where the register
is encoded in the opcode...
> Syntax: JP
> Opcode: $20 ll hh
>
> where = (hh AND $3F)*256+ll
>I'm not sure whether the "AND $3F" is actually useful.
>Maybe you should simply let the robot break down when the address is out of
>range.
Hm, not nice :-( Although...
>I even think that we should have the "robot EXE format" tell which part of the
>RAM will be used for code and which part for data. Executing data or
>reading/writing code should be illegal.
>The reason for this is that it makes debugging much simpler. If the robot
>bytecode interpreter reports "robot shut down: writing to code area at $1420",
>you can easily spot the error in your program or compiler. However, if the
>write is allowed, you will probably see the robot do very strange things
>without having a clue what's wrong.
Hm... I'll sleep on it over night...
>> Syntax: PSHB
> ...
>Maybe you can better describe it as "byte is fetched, then sign extended,
>resulting word is pushed to the stack".
Hm, ok.
>Suggestion:
>Syntax: PSHE
>Opcode: $37 nn
>where = nn
>Pops two words from the a-stack.
>The topmost is called and the other one .
>Depending on , a byte specified by one of the following environment
>items is pushed to the a-stack:
> = 0 env[][].contents
> = 1 env[][].data
