Hacker News Reader

Comment by dmitrygr | Hacker News Reader

[flagged]

It's an 8 bit unaligned encoding, so this matters very little

From an ergonomics perspective big-endian is the little-endian of stack based machines. Register truncation is the big reason why from an ergonomics perspective we prefer little-endian, but in stack based machines the equivalent is pop truncation. But the behavior between these is reversed between the two machine types. Big endian is the layout by which pop-ing one byte off the stack gives you the truncated number.

math is still done LSB-to-MSB

why that reaction? what impact does one or the other entail?

well, if i wanted to emulate this on some tiny piece of hardware, as one does.

Little endian is generally a lot more amenable to emulation, since math of almost all kinds of done LSB-to-MSB

I don't think you can emulate it on a tiny piece of hardware; the smallest full Uxn/Varvara implementation I've seen so far is the GameBoy Advance, which has 384KiB of RAM. On the other hand, you've previously been able to emulate some pretty astonishing things on pretty astonishing hardware.

There are a lot of minor things in Uxn and Varvara that make them hard to emulate efficiently. Extensive use of self-modifying code, memory-mapped I/O, and using a stack instruction set, for example.

I'm interested to hear how you'd redesign Uxn/Varvara to be easy to emulate on some tiny piece of hardware; of everyone in the world, you're probably the best person to answer that question. Little-endian, check. What else?

LE is all i'd ask for. I bet I could get it to run on an 8008 even without that change, but LE would make it easier to emulate :)

Stack-based actually helps (registers suck up RAM fast). Self-mod does not matter to emulators. It would for a JIT, but that is a separate story.

There's no requirement that stacks grow upwards in Varvara.

If your stacks grew downwards then you could use LE instructions to operate on 16-bit values on the stack. You'd still need to support loading from BE memory into the LE stack but that might not be too bad (two 8-bit operations instead of one 16-bit operation).

The device ports are also specified as BE so in theory you'd need to split those reads/writes up too. However, in almost all cases those are done directly from the stack values so I bet most ROMs would work fine with LE devices and LE stacks. LE devices would only cause issues when someone used 8-bit reads/writes from part of a 16-bit port.

How would you hook up 64K of RAM to an 8008? Through some shift registers?

SPI RAM bit-banged via some IO ports is pretty easy, same as here: http://dmitry.gr/?r=05.Projects&proj=35.%20Linux4004

Awesome, thanks for the link! I didn't remember that aspect of the 4004 project.

This would be a pretty amazing project. I wonder if you could get existing Uxn/Varvara applications like the Left text editor or Orca to run fast enough to be usable. Presumably for Orca you'd want to hook up external sound hardware rather than trying to bitbang the sound on the 8008, and I guess the same is even more true of a framebuffer.

If you were bitbanging RAM access at 7kbps it might be hard to get it to run instructions fast enough to be usable, though.

i think 8008 would be much faster :)

i'll look into this

Uxn uses big endian primarily because it is meant to be easily assembled from (or disassembled into) a thin programming language called Tal. I think Tal is meant to be the highest-level language available in this platform, so it should be as convenient as possible without being too fat---`#1234` in Tal would ideally be assembled to two bytes `12 34` therefore.

Big endian is a totally illogical choice these days, unless you're making network hardware.

Reply on news.ycombinator.com