minor corrections to the shorts section

This commit is contained in:
sejo 2024-03-14 19:38:58 +01:00
parent a339bd307c
commit 0e928f46a7
1 changed files with 11 additions and 8 deletions

View File

@ -32,10 +32,13 @@ how do we deal with them?
counting from right to left, the 6th bit of a byte that encodes an instruction for the uxn computer is a binary flag that indicates if the short mode is set or not.
whenever the short mode is enabled, i.e. when that bit is 1 instead of 0, the uxn cpu will perform the instruction given by the first 5 bits (the opcode) but using pairs of bytes instead of single bytes.
whenever the short mode is enabled, i.e. when that bit is 1 instead of 0, the uxn cpu will perform the instruction indicated by the first 5 bits (the opcode) but using pairs of bytes instead of single bytes.
the byte that is deeper inside the stack will be the "high" byte of the short, and the byte that is closer to the top of the stack will be the "low" byte of the short.
you can see this illustrated in the notes shared by Rostiger:
=> https://nchrs.xyz/uxn_notes.html nchrs: uxn notes
in uxntal, we indicate that we want to set this flag adding the digit '2' to the end of an instruction mnemonic.
let's see some examples!
@ -56,7 +59,7 @@ this would be the final state of the stack:
32 <- top
```
in the previous day we mentioned that the literal hex rune (#) is a shorthand for the LIT instruction. therefore we could have written our code as follows:
in the previous day, we mentioned that the literal hex rune (#) is a shorthand for the LIT instruction. therefore we could have written our code as follows:
```
LIT 02 LIT 30 ADD ( assembled code: 80 02 80 30 18 )
@ -86,7 +89,7 @@ what would be the state of the stack after executing this code?
#0004 #0008 ADD
```
that's right! the stack will have the following values, because we are pushing 4 bytes down onto the stack, ADDing the two of them closest to the top, and pushing the result down onto the stack
that's right! because we are pushing 4 bytes down onto the stack, ADDing the two of them closest to the top (00 and 08), and pushing the result down onto the stack, the stack will end with the following values:
```
00 04 08 <- top
@ -114,7 +117,7 @@ the stack ends up looking as follows:
00 0c <- top
```
we might not need to think too much about the per-byte manipulations of arithmetic operations, because normally we can think that they are doing the same operation as before, but using pairs of bytes instead of single bytes. their order not really changes.
we might not need to think too much about the bytewise manipulations of arithmetic operations, because normally we can think that they are doing the same operation as before, but using pairs of bytes instead of single bytes. their order doesn't really change.
in any case, it's useful to keep in mind how they work for some behaviors we might need later :)
@ -138,17 +141,17 @@ DEI ( address -- value )
what do you think that DEO2 and DEI2 would do?
in the case of the short mode of DEO and DEI, the short aspect applies to the value to output or input, and not to the address.
in the case of the short mode of DEO and DEI, the short aspect applies to the value to output or input only, and not to the address.
remember that the 256 i/o addresses are covered using one byte only already, so using one short for them would be redundant: the high byte would be always 00.
considering this, the following are the behaviors that we can expect:
the DEO2 instruction needs a value (1 short) to output, and an i/o address (1 byte) in the stack, in order to output that value to that address. therefore it needs a total of 3 bytes in the stack to operate.
the DEO2 instruction needs in the stack a value (1 short) to output, and an i/o address (1 byte), in order to output that value to that address. therefore it needs a total of 3 bytes in the stack to operate.
on the other hand, the DEI2 instruction needs an i/o address (1 byte) in the stack, and it will push down onto the stack the value (1 short) that corresponds to that input.
on the other hand, the DEI2 instruction needs in the stack an i/o address (1 byte), and it will push down onto the stack the value (1 short) that corresponds to that read input.
in the following section we will see some examples where we'll be able to use these instructions.
in the following section, we will see some examples where we'll be able to use these instructions.
the 'write' port of the console device that we used last time has a size of 1 byte, so we can't really use these new instructions in a meaningful way with it.