Hi!

Im recently using uxn quite a lot and must say that I rather like
it - having a minimalistic, clearly defined, portable program
execution environment that still can be understood in detail and
addresses a local, personal level of software development feels
like a great liberation from overly complex and overly ambitious
previous attempts at VM design. Besides, the design is simply a
good mixture of simplicity, practicality and elegance.

What interests me in particular is using uxn as a "platform", a
substrate on which to develop and deploy programs of limited size.
The simplicity of the system makes porting or re-implementing the
VM a viable task, even for small and constrained targets.

A problem I see with this point of view is that this means that the
"platform" has to be seen separate from the VM implementations,
which is currently not done. There are some subtle and not so subtle
differences between (say) SDL uxn and uxn11 that can and will trip
up and annoy users who are not willing or able to use their own
customized uxn VM. Examples are the event-loop timeout implemented
in SDL uxn[1], the experimental stack-mapping feature in uxn11,
recent operator encoding changes, etc.

Now, I understand that there must be room for experimentation, and
the uxn descriptions clearly state that backwards compatibility is
not a goal. That's understandable, when one wants to avoid keeping
obsolete or unpleasant baggage around.

But what _can_ be done is to at least organize and advertise changes
in a consistent manner. All that is needed is some informal "revision"
number identifying the uxn (and ideally also the varvara) variant
supported. So a VM implementation and roms developed could simply
state the revision they support or for which revision they have
been built[2]. Otherwise users will get endlessly confused by roms
work on one implementation or implementatiom-version and not on
another, which is rather frustrating.

For device-level changes this is harder, only some sort of access
to "feature flags" would be a complete technical solution, but
sounds like overkill. I can only try to stress the importance of
keeping existing devices as they are.

Currently it is for example not possible to set and read the
stack-pointer in a way that works on both uxn11 and SDL uxn (uxn32
too, I guess)[3]. Using a separate "memory" device allowing the
stack remap (perhaps even with the option for general memory features
- "bank switching" or "page fault" come to mind) might have 
been a better option.

Anyway, just a suggestion. An official uxn- (and possibly also
varvara-) revision, clearly stated in the documentation of the
platform and its implementations would be a small but useful step
in making its progress more transparent to users and implementers
alike.


felix

--

[1] After an exchange on #uxn this seems to be addressed in the
    future, for which I am very grateful.
[2] There could even be a dedicated system device port allowing 
    the revision to be read via DEO, kind of like a CPUID 
    instruction (just as an idea).
[3] In fact, direct access to the stack-pointer is rather 
    important, especially for language implementations on top 
    of uxn. IIRC the new stack-mapping feature allows this,
    but I'm not sure.

Hi Felix,

I understand your concerns, you're not the first person to ask for
something akin to versioning.

Uxn, the VM, as it is now, is likely done. I doubt it will be seeing
changes again anytime soon. I have plans to finalize my opcode testing
rom in the next couple of days and call it a release candidate.

Varvara, on the other hand, is a bit trickier because beyond
versioning, not all emulators will be specs compliant dependent on
their system's capabilities. My goal is instead to find a way to infer
version.

Imagine, something like the test.rom, that runs through a series of
tests like "Did you hear a C4 piano note", "is the red dot at the
center of the blue square", etc.. At the end of the test, the rom will
print a compatibility index.

Around the time Varvara turns 2 years old, I should have written
something around  100k lines of Uxntal and be able to say if the specs
covers most grounds. Hopefully the documentation will be able to cover
everything about its implementation details. That will be the only
version, I'm inching closer to this, but I still need more time to
write more varied programs, and I don't want to be at the same time
monitoring compatibility with all these different emulators.

Don't think of a Varvara as a platform just yet, at best, it's
something that can inspire others to explore their own ideas of how a
VM can be used to preserve their own projects. There is very little
experimentation done in this space and it's sort of in the research
phase right now.

But if you feel strongly about uxn11's stack access, for example,
write software that use it, demonstrate that this feature is worth
keeping and get others to replicate it into their own varvara
emulators. It's a playground, so far it has grown organically to match
the needs of the people writing uxn programs :) So do that, write
programs, find out what you need in your project and let's talk about
it.



On 6/9/22, felix.winkelmann@bevuta.com <felix.winkelmann@bevuta.com> wrote:
> Hi!
>
> Im recently using uxn quite a lot and must say that I rather like
> it - having a minimalistic, clearly defined, portable program
> execution environment that still can be understood in detail and
> addresses a local, personal level of software development feels
> like a great liberation from overly complex and overly ambitious
> previous attempts at VM design. Besides, the design is simply a
> good mixture of simplicity, practicality and elegance.
>
> What interests me in particular is using uxn as a "platform", a
> substrate on which to develop and deploy programs of limited size.
> The simplicity of the system makes porting or re-implementing the
> VM a viable task, even for small and constrained targets.
>
> A problem I see with this point of view is that this means that the
> "platform" has to be seen separate from the VM implementations,
> which is currently not done. There are some subtle and not so subtle
> differences between (say) SDL uxn and uxn11 that can and will trip
> up and annoy users who are not willing or able to use their own
> customized uxn VM. Examples are the event-loop timeout implemented
> in SDL uxn[1], the experimental stack-mapping feature in uxn11,
> recent operator encoding changes, etc.
>
> Now, I understand that there must be room for experimentation, and
> the uxn descriptions clearly state that backwards compatibility is
> not a goal. That's understandable, when one wants to avoid keeping
> obsolete or unpleasant baggage around.
>
> But what _can_ be done is to at least organize and advertise changes
> in a consistent manner. All that is needed is some informal "revision"
> number identifying the uxn (and ideally also the varvara) variant
> supported. So a VM implementation and roms developed could simply
> state the revision they support or for which revision they have
> been built[2]. Otherwise users will get endlessly confused by roms
> work on one implementation or implementatiom-version and not on
> another, which is rather frustrating.
>
> For device-level changes this is harder, only some sort of access
> to "feature flags" would be a complete technical solution, but
> sounds like overkill. I can only try to stress the importance of
> keeping existing devices as they are.
>
> Currently it is for example not possible to set and read the
> stack-pointer in a way that works on both uxn11 and SDL uxn (uxn32
> too, I guess)[3]. Using a separate "memory" device allowing the
> stack remap (perhaps even with the option for general memory features
> - "bank switching" or "page fault" come to mind) might have
> been a better option.
>
> Anyway, just a suggestion. An official uxn- (and possibly also
> varvara-) revision, clearly stated in the documentation of the
> platform and its implementations would be a small but useful step
> in making its progress more transparent to users and implementers
> alike.
>
>
> felix
>
> --
>
> [1] After an exchange on #uxn this seems to be addressed in the
>     future, for which I am very grateful.
> [2] There could even be a dedicated system device port allowing
>     the revision to be read via DEO, kind of like a CPUID
>     instruction (just as an idea).
> [3] In fact, direct access to the stack-pointer is rather
>     important, especially for language implementations on top
>     of uxn. IIRC the new stack-mapping feature allows this,
>     but I'm not sure.
>
>