Hello everyone,
Long time no talk, I had a question and I'd like your opinion.
binarycat needed raw byte values for their project, and I did a quick
scan of some of my own projects and found a good couple of .zplabel
STH, which should really be more like LITr -zplabel
So I was thinking, what would you say if on top of : for raw label
shorts, I added =label for raw shorts, and -label for raw bytes?
Consider your macros that might begin with - or =.
Let me know what you think :)
Dll
Hey Devine!
Could you clarify it with some examples? From your first paragraph I
think I get the -label one (it gets replaced by the raw, one byte
address assigned to the label? (specifically the least significant byte
of the address?)), but I'm having trouble finding the difference between
:label and =label in your proposal.
In any case, it sounds useful to leverage the affordances of LITr!
sejo
On Wed, Nov 09, 2022 at 08:58:53AM -0800, Devine Lu Linvega wrote:
>So I was thinking, what would you say if on top of : for raw label>shorts, I added =label for raw shorts, and -label for raw bytes?>Consider your macros that might begin with - or =.
I think it could be quite a rarely-used feature, and I had some
inspiration from Huffman coding…
What about a double rune?
We can keep the unadorned “:” for raw shorts, but we could also use “:;”
for the same thing. We can then use “:.” for raw zeropage bytes and even
“:,” for raw relative bytes.
I know it heads off in a new direction and makes the assembler a little
harder (checking for “&” for sublabels now needs to check the second or
third char, depending) but there's less human memory needed to remember
which literal rune corresponds with which raw rune.
Best wishes,
Andy
> Could you clarify it with some examples? From your first paragraph I think I get the -label one (it gets replaced by the raw, one byte address assigned to the label? (specifically the least significant byte of the address?)), but I'm having trouble finding the difference between :label and =label in your proposal.
I've updated the rune chart, when you see it side by side it's easier
to see what this new rune does. Specifically the least significant
byte of the address, is correct :)
https://wiki.xxiivv.com/site/uxntal.html
The :label and =label do the same thing. I'm not sure if I want to
change the rune altogether, add another one, or just keep : yet.
binarycat suggested that I use ^ for raw byte, but I'm not 100% sold
on this, since some people use ^ for bytes and * for shorts, I think
it'd be weird not to use * as the lit rune too.. And I don't like that
both characters need mod key for input(I type with one hand 90% of the
time.)
> I think it could be quite a rarely-used feature, and I had some
inspiration
I found about 20ish instances in code where using the rune removed 1
byte, the typical case is when I'm loading a zp value in the return
stack for a comparison loop:
https://git.sr.ht/~rabbits/left/tree/main/item/src/left.tal#L359> We can keep the unadorned “:” for raw shorts, but we could also use “:;”
for the same thing. We can then use “:.” for raw zeropage bytes and even
“:,” for raw relative bytes.
I've been toying around with the idea myself too, I like this a lot.
One thing I'd love to do is a different sort of editor, which is more
"aware" of the code and handles this sort of things internally and
could draw these rune sequences as a single rune or something.
It wouldn't be uxntal per-say, but it would have a textual equivalence
that would use multiple characters to express the token type. I've
been noodling with Smalltalk-80 these days and I've been slowly
porting some of the ideas I like over to Left - it has given me ideas
for a new language that could compile to uxntal which would be even
more visual than the routine navigator in Left.
I've implemented a quick version of the -rune so anyone can noodle
around with it, I'm not sold on the - character as a rune, it's
something I use as a spacer between words usually. But at least you
can try it out. It's especially useful for keeping tables of structs,
if you do that sort of gymnastics in your code.
On Thu, 2022-11-10 at 08:08 -0800, Hundred Rabbits wrote:
> even “:,” for raw relative bytes.
Yes... \o/ ...raw relative too please. I'll take whatever rune it
gets.
...and the 2 character rune idea really is worth the second char! All
the raw ones should have one prefix and the ones with implicit LIT a
different one. Grouping them would speed up (at least my) reading of
the code by instantly getting reminded which one has the ™LIT inside™.
Hmmm ...(insert rotating hourglass here)... maybe even with an own
prefix for ™LITr inside™? (Now you know who is writing this?) But
that's nice and not strictly necessary. When everything with labels,
constants and addresses is available raw, I'm willing to manually
prefix it with LIT/LITr where necessary.
So last night I tried implementing the raw rel, but I couldn't figure
out what the value of the raw byte had to be for it to work in a loop
for example, I'm a kind of a newbie when it comes to manipulating the
raw relative bytes. The raw rel rune will likely be `_`, but I'm not
sure what sort of offset it should have.
Since I've never really done much iterating with the return stack,
could anyone write me a hello world using the rst so I can test this
out?
On Thu, 2022-11-10 at 15:36 -0800, Hundred Rabbits wrote:
> The raw rel rune will likely be `_`, but I'm not sure what sort of> offset it should have.>> Since I've never really done much iterating with the return stack,> could anyone write me a hello world using the rst so I can test >> this out?
```
( zstrr - print zstring via r-stack )
|0100
;&zstrr JSR2 "Hello, 20 "UXN! 0a 00
#010f DEO
BRK
&zstrrnext
LITr 18 DEOr INC2r
&zstrr ( -- | retaddr -- )
DUP2r LDAr DUPr LITr f6 JCNr
POPr INC2r
JMP2r ( -- | -- )
```
Will the `LITr f6` be `LITr _zstrrnext` then?
First off, I've implemented the _rune to write raw relative byte address.
But more importantly.. you've written an inline string routine?!
One of the coolest uxntal thing I've seen recently.
Kudos
On Thu, 2022-11-10 at 20:56 -0800, Hundred Rabbits wrote:
> First off, I've implemented the _rune to write raw relative byte> address.
\o/ ____( Thanks! )
> But more importantly.. you've written an inline string routine?!> One of the coolest uxntal thing I've seen recently.>> Kudos
Thanks again! ;-)
It was part of my experiments with UXN's stack symmetry, but the r-
stack version was sleeping in an unpublished tmp dir because of the
missing rune. I added the r-stack version just some hours ago to be
prepared to put in the new rune.
https://yeti.tilde.institute/brain/uxn.html#jsr-followed-by-data-1.talhttps://yeti.tilde.institute/brain/uxn.html#jsr-followed-by-data-2.tal
I remember data being placed directly after a call instruction to be
read via the return address as pointer from 8 bit days, so I just
played with it in UXN.
Probably using both stacks can yield the same functionality with less
code, but I focused at demonstrating the stack duality instead of
optimal code.
My notes still haven't got the update to reflect the vanished single
char rune. Hopefully I'll update them soon for all rune changes.
_o/"
It's nuts, it took me a good while to untangle this whole thing in my
head, when I understood what was going on, it shattered my brain, well
done. I will be using this routine.
Furthermore, I feel honored to to be able to contribute to improving
it ever slightly, by removing `DUP2r LDAr`, for `LDAkr`.
On Thu, 2022-11-10 at 21:26 -0800, Hundred Rabbits wrote:
> It's nuts, it took me a good while to untangle this whole thing in my> head, when I understood what was going on, it shattered my brain,> well done. I will be using this routine.
;-)
With such a call interpreting "opcodes" following it, a "VM" like
Sweet16 for UXN could be built.
> Furthermore, I feel honored to to be able to contribute to improving> it ever slightly, by removing `DUP2r LDAr`, for `LDAkr`.
Thanks!
I applied that to both examples.
Sure I need a sharper eye for places where the k makes sense.