Hi everyone,

Sorry I've been quiet on the list, I've been working hard at improving
the varvara docs and creating examples for the different devices and
things. There has been a lot of activity lately, between the FPGA
port, the WASM implementation, etc.. I wanted to do a little change to
the File device and I wanted to know what you thought, so those who
don't know, the File device has a stat* port:

> The directory listing for a single file or directory can be obtained when File/stat* is written, and will write the same format as above, including the newline, into the memory buffer. If File/success* reads zero, the file or directory doesn't exist or the region is too small to fit the line.

The only usage I've ever had of the port was ever to get the first 4
characters, which look like these:

There's a ton of good ideas in there, as people implement them in
their projects, I'll refer them to this thread so they can follow your
standards. :)

I'm on the 16-bit relative thing, i'll add soon :)

What would the align directive do?

On 9/5/23, felix.winkelmann@bevuta.com <felix.winkelmann@bevuta.com> wrote:
>> You've been ahead of the curve for most recent features, if you had to
>> think of one from uxnasm38 that you think will soon make it's way
>> upstream, what do you think it would be? :)
>
> I've not looked at uxnasm38, but my personal wishlist is this:
>
> - encoding raw 16 bit relative offsets
> - an "align" directive
>

It seems I'm only playing catch up with your features! it's really
cool you've gotten to the point where you needed lambdas too. I
thought about backward lambdas, but I found it was messing up with
validation a bit, since I never explicitly want to declare stack
definitions to backward local labels, like the entry label in a loop.
But it might be worth adding at some point if someone finds a use for
it. I love using lambdas, it has totally changed the way I do controls
routing, it was very annoying to have to give names to these sorts of
disposable labels:
https://git.sr.ht/~rabbits/left/tree/main/item/src/left.tal#L313

For anyone reading and wanting to have a look at zzo38's assembler,
here's the code: https://github.com/zzo38/uxn38/blob/trunk/uxnasm.c

> Can arity checkers detect infinite recursion? My intuition is that this is the halting problem, and therefore impossible. So removing bounds checks on stack ops leaves the door open for stack corruption and therefore very odd and unpredictable behaviour in such cases.

I'm not sure how this fits with the halting problem, but in uxntal,
the arity checker will not let you recurse if the body that you're
jumping to imbalances the stack, is that an issue you've had with
uxnbal? It validates most recursion that I've found but it's possible
that it misses some specific patterns. I have yet to implement lambdas
support, that one is a bit tricky. Right now, I just mark these jumps
as unsafe.

Hi bd!

Thanks for clarifying and counting cycles, that paints a much clearer picture :)

I've spent most of yesterday playing with this and being to handle
testing code at the uxntal level is very nice, having to flag the
emulator with debug wouldn't be as practical. Oquonie already has a
debug/release file setup, and so it was easy to add stack depth
checking to my vectors.

At runtime, I found that at the root level of each vector, DEI2 both
wst/rst and comparing against #0101 was really nice, what I do is
print the stack(#010e DEO) and trigger a crash(#010f DEO) on
imbalance. This replicates the earlier behavior somewhat, and finding

hell yea, that's the spirit.

Do you think there's any use for circular stacks, like some sort of
utility would could make from it? Looking it up there seems to be a
couple of things for caching. I can imagine pushing to the
near-infinite stack when streaming bytes from a file, and having a
kind of cache to grab things from the past. Any other idea?

On 9/2/23, felix.winkelmann@bevuta.com <felix.winkelmann@bevuta.com> wrote:
>> I wanted to ask you all something, that is probably going to sound
>> nuts. The way the VM is currently implemented(in most cases), is for
>> it to check for stack overflow and underflow during each opcode.
>>
>> But what if, we didn't.

Hi everyone,

I wanted to ask you all something, that is probably going to sound
nuts. The way the VM is currently implemented(in most cases), is for
it to check for stack overflow and underflow during each opcode.

But what if, we didn't.

As uxntal arity checking tools are getting better, and since we have
the system/wst and system/rst ports to check for stack depth when and
where we need to. Do we really need to check on opcode? Maybe not. I
kind of like the idea of a uxn core that cannot error, error handling
is kind of mess and I have yet to see someone other than me use it.
But not only that, it's slow as hell, and since this is destined to be

Hi Wim,

That's very interesting, in parallel to this, I've been exchanging
emails with Felix on that same topic. I have had a nasty wasp sting on
my right hand, so I can't type a long reply, but I just wanted to pass
along the code that I've been playing with.

Inspired by the T4(transputer) and its idea of links to other
transputers, my approach was to think of a Link device(#f0) as a way
to hook up to other Uxns, and distribute a task. To give you a taste
of the implementation, here's a uxntal project that has the equivalent
of an occam PAR block, where each #f0 DEO2, requests a uxn to do a
vector evaluation of the address on a free thread, with a copy of the
current stack state. The implementation itself is non-intrusive, and

> Say I dump UXN machine code and encounter an immediate branch but have no symbolic information of the code, how should this then be shown?

The way I display it in disassembly usually is like -9/+9 type things,
because having the direction of the jump sometimes helps to understand
what it is, especially for loops. But normally, in disassembly, I have
the symbols file, so I grab the symbol at the relative absolute
address:

https://wiki.xxiivv.com/site/bicycle.html

Bicycle is also a good tool to test assembly/disassembly, how uxntal
maps to bytes, you should try it out :)

> Oh, all these runes confuse me... Can someone write a rune tutorial, please? :-)