Sorry, away from my computer this week (and I will be until Friday), so I haven't done anything lately. On the other hand, my on-calc TI programs are doing fine

Woo, that's great to hear! Have you shared those with us? I don't think you have, which means that when you have time it behooves you to try post up a Your Projects topic about them.

I don't think anyone would use them

Anyway, implemented the full brainf*ck instruction set just because I could.

As part of the VM, or as part of another random project just for fun? I'd love to see how many instructions per second it can process.

Part of the VM. It actually does have a practical purpose, because it allows me to test the other parts of the VM a lot more easily than with that massive Java instruction set, where any number of things could go wrong and prevent testing.

Bump:

I've been kind of busy with other, more immediate things recently, but Khavi is still progressing. If everything goes well, I should have a working demo by the end of this week.

However, this demonstration will leave out a lot of crucial stuff, so here's a partial list of things waiting to be completed:

* Full multi-threading support
* Privileges
* Khavi Scripting Language (KSL): This will be almost entirely undocumented, so don't worry about learning a new language. The syntax is only slightly better than brainf*ck, so you're not missing out on much except the chance to brick your calc
* Shell dependencies: This will most likely be one of the last things implemented
* Interpreter run-time libraries: Dependent on KSL and the booting process
* Native interfaces: Depends heavily on KSL
* Full Java VM instruction set
* Full Lua instruction set: Relatively close to completion
* Boot code: It's a major PITA to write and will probably be one of the last things written, since it's dependent on so many other factors. Also depends somewhat on KSL
* The context switcher: It's written, but I need to copy it from my notebook
* Memory management (distinct from garbage collection): Lookup-tables, lookup-tables, lookup-tables
* Garbage collection: Screw it. Garbage collection is for wimps
* Anything else I've forgotten: Have you seen the size of this list?

KSL kind of replaces the use for Brainf*ck I mentioned in my last post, but the Brainf*ck instruction set is already written, so whatever.

Dang it, Kllrnohj. You were way too accurate about the scale of the project.

Anyway, as a general update, got a lot of work done on the system libraries, Brainf*ck is now available on-calc, the context switcher can now [hopefully] play nicely with C/ASM programs as well as interpreted languages, there are still some bugs in the Khavi boot code causing crashes 30 milliseconds after initialization, Java sucks, etc...

Basically, there's a lot of work yet to be done, but it's gradually getting there.

And that, ladies and gentlemen, is why Kerm puts up with my shit.



Still say you should try porting Dalvik instead...

What can I say, he may be a pain in the neck, but he knows what he's talking about.

I'm still stubborn about writing my own VM. It's quite a good way to learn how they work and as a bonus, I get to write all of the fundamentals of a kernel

I'm confused by this. You really want to run Java without garbage collection?

That was a bit of a joke because the GC algorithms are so nasty to code.

Not only are Garbage Collection algorithms horrendous to code, even a well-programmed one tends to make errors, as far as I can tell. At least from the example that Java sets, not that that's a very good example, or perhaps the fault lies in poorly-coded applications.

I took Kllrohj's advice and looked into Dalvik. While I'll admit it's cool, I have virtually no hope of actually being able to pull a port off. So Khavi it is. Anyway, I set up a nice little Google Code repository for it. I probably need to commit the updated stuff though...

EDIT: Khavi is also going to be released under the GPL, in case anyone cares.

Added some math stuff to Khavi's library (Sine, Cosine, floating point Floor, floating point ceiling), fixed a major bug in Khavi's floating point modulo routine, wrote a functioning process selector for the context switcher, and started on Garbage collection. More to come.

Progress! I can only assume you're using the new software float support from libGCC in the [Cemetech] PrizmSDK? I wish we knew for sure about hardware floats.

Yeah, using GCC for the floating point stuff saves a ton of code/time. As for hardware floats, the opcodes throw exceptions on the processor and the OS doesn't use them in any of the parts Simon or I have disassembled.

Meh, that's very frustrating. Although I'm otherwise happy with Casio for the Prizm, I do somewhat question the wisdom of a processor with no FPU put into a calculator...

Casio uses a powerful BCD unit for floating point calculations. However, it is undocumented by Renesas.

Oh realllly? Can you tell us any more about that, such as any instructions you've figured out thus far that let it be poked, or routines that use it that could be used to recover instruction opcodes?