Reviving the Vera project!

[Jim e]

The "8k limit" doesn't technically apply, simply because theres nothing below $9d95. But a limit is still imposed, depending on what security is set, executing on certain ram pages will cause the hardware and cpu to reset.

[CoBB]

I don't get why everyone is talking about an 8Kb limit...

Tradition.

The "8k limit" doesn't technically apply, simply because theres nothing below $9d95. But a limit is still imposed, depending on what security is set, executing on certain ram pages will cause the hardware and cpu to reset.

But in the end it is possible on all models to have a contiguous 32k of executable RAM mapped, isn’t it? Not that it matters much for most applications...

[King Harold]

It is.
On the other hand, you might want to make sure that data (not code) isn't executed because that could in theory be more harmful than a reset, but a reset won't make anyone happy either, and just how dangerous could some code be?

[Timendus]

So much to discuss

rst is smaller and faster than a call (it's a single byte). Typically you'd put a simple function that is called a lot there, hence the TIOS using them for things like bcalls or copying nine bytes of data to OP1.

Okay, but talking bits and busses, what does it DO? According to some specs it "restarts to a location", but what is restarting supposed to mean in this context?

Ticalc.org says

Code: Select all

#define B_CALL(xxxx) rst 28h \ .dw xxxx
#define B_JUMP(xxxx) call 50h \ .dw xxxx 

What code is at 28h and 50h? How does it know where it's called from if it's some kind of wacky jump?

as long as you keep modularity in mind so it can be swapped in at a later date without breaking everything.

Of course, that's only good programming practice.

Think about the consequences. I guess that's exactly what Dunkels did before coming up with protothreads.

Heheh Making all the same mistakes should be part of the fun, shouldn't it? Maybe we'll be able to laugh in his face

Anyway, I have very strong doubts whether supporting C on the user end is a really good idea. It is an extreme amount of hassle if you want to make it work with multitasking and all that. I'd rather propose the following: provide support for a managed language and assembly.

Allthough I think that's a very good idea, it would be a project of it's own...
What did you have in mind?

Depending on how it is implemented it could potentially be used to run Vera programs on the regular TIOS. It's something I've been considering writing myself recently, having done some work with the QuakeC VM.

That's a good argument in favour of such a language, but once more, that'd be a project of it's own. And I'm not sure CoBB was talking about a VM here..?

I think this certainly should be a topic of debate. Are we talking about a compiled language, something interpreted or JIT compilation? What kind of syntactical structures should it have? But most importantly; how is it supposed to be going to interface with the Vera kernel? Maybe that should be the place to start, bearing pure ASM (and perhaps C?) code in mind.

Would it be possible to implement a compressed file system for RAM/archive?

Sure it would, once we've got the file system abstraction API stuff done, feel free to write one I doubt it'll give you very good ratios though.

has anyone talked to tari yet? he's working on his own operating system and last I heard he was making good progress

Who is that and what are the goals of his project?

I still need Jim's address (if you want in, that is ). I intend to move this discussion to the more controlled and less noisy environment of our e-mail inboxes some time soon. But any way, keep up the discussion as it's given some really good focus areas so far!

[King Harold]

On RST's and the weird macro's

PC+1 is pushed on the stack, and PC is then set to 0,8,$10,$18,$20,$28,$30 or $38, the address is determined by a bitfield of 3 bits.
Opcode: 11[bitfield]111, where the bitfield is bits 3-5 of the address.
RST is just a 1-byte call to a fixed address (fixed in a sense that the address is part of the instruction so there are only 8 different RST's), it behaves like a normal call to that address, but of course it is faster since it is smaller.
The macro's work by pop-ing from the stack, reading the DW there, and pushing the new address back on to return to later. They then work their magic on that DW and return.
RST doesn't really "restart" the cpu, if it helps just think of RST as "INT" (the instruction that calls some stuff that it executes in ring0) z80's don't have rings so it works like a call.

On kernel threads

The standard interrupt (rst $38 ) is in effect a kernel-owned thread.. user programs shouldn't really be allowed to disable interrupts (it gives them power over the OS) but it's just a calc so it won't matter much..

[CoBB]

What code is at 28h and 50h? How does it know where it's called from if it's some kind of wacky jump?[/code]
rst is completely equivalent to call, the difference is that it takes only one byte and less time, but it can only be used with eight addresses. It is a potentially very useful instruction.

Heheh Making all the same mistakes should be part of the fun, shouldn't it? Maybe we'll be able to laugh in his face

Provided that we'll still have the energy and mood for laughing.

Allthough I think that's a very good idea, it would be a project of it's own...

Yes, it would be a clearly separate layer.

What did you have in mind?

Nothing specific for the moment. If we decide to choose this route, we should define both the VM and the high-level language from scratch. In general terms I was thinking about a pointerless (important!) structured language and no garbage collection, something like a sensible subset of C extended with parallelism and a better type system.

And I'm not sure CoBB was talking about a VM here..?

I was. Though it might be possible to define the VM's low-level language and semantics in a way that would make native code compilation practical (basically a macro-like expansion of each virtual assembly instruction) in some cases, a bytecode interpreter would be easier to handle and programs could be very small. Besides, relocation would suddenly become a non-issue, so they could be kept in flash.

I think this certainly should be a topic of debate. Are we talking about a compiled language, something interpreted or JIT compilation?

Definitely no JIT. Let's keep the dreams at least a little bit realistic.

What kind of syntactical structures should it have? But most importantly; how is it supposed to be going to interface with the Vera kernel? Maybe that should be the place to start, bearing pure ASM (and perhaps C?) code in mind.

These questions are too early to ask.

[Timendus]

Okay, thanks a lot for that explaination! I deduced as much, but it doesn't really make sense to the untrained eye. Why would you want to call the Ti-OS routines through 28h, instead of just calling them directly? Because I assume that jumping to $28, working with the stack to extract the right jump address, and jumping to it, is not any faster than just doing a call... Does that have something to do with bypassing the 8k limit?

Concerning threads; of course we COULD just do it the Ti-OS way and put everything we'd ever want to check at $38 and leave it at that, but a) that wouldn't be as cool, b) that would give quite a mess there (different bits of domain code) unless we get ourselves into some serious preprocessing crap (which I love, but doesn't usually add to the simplicity of the code ) and c) it wouldn't allow user space applications to run in a threaded way, or allow them to fork, and that would be a shame.

On flash file systems, maybe this is worth a look:
http://www.embedded.com/2000/0012/0012ia2.htm

Edit: Ah, cross post, I'll get back to you in a moment, CoBB, time for lunch first

[benryves]

Okay, thanks a lot for that explaination! I deduced as much, but it doesn't really make sense to the untrained eye. Why would you want to call the Ti-OS routines through 28h, instead of just calling them directly? Because I assume that jumping to $28, working with the stack to extract the right jump address, and jumping to it, is not any faster than just doing a call... Does that have something to do with bypassing the 8k limit?

It allows for cross-page calls (ie, if the target routine is on a memory page that isn't currently swapped in, the bcall handler at $28 will swap it in before jumping to it). The jump table references both a page number and an address within that page.

[Timendus]

rst is completely equivalent to call, the difference is that it takes only one byte and less time, but it can only be used with eight addresses. It is a potentially very useful instruction.

Obviously, used in the way I mentioned above, it has neither of those advantages.

Code: Select all

#define B_CALL(xxxx) rst 28h \ .dw xxxx 

A B_CALL(_whatever) will be just as many bytes in your program code as a call _whatever, thanks to the DW, and it'll probably be much slower because the routine at $28 has to do some voodoo magic before it jumps. So I'm glad Ben pointed out the paging issue But you're right that it could be potentially very useful in the sense that you could put eight often used functions there.

If we decide to choose this route, we should define both the VM and the high-level language from scratch. In general terms I was thinking about a pointerless (important!) structured language and no garbage collection, something like a sensible subset of C extended with parallelism and a better type system. [...] it might be possible to define the VM's low-level language and semantics in a way that would make native code compilation practical (basically a macro-like expansion of each virtual assembly instruction) in some cases, a bytecode interpreter would be easier to handle and programs could be very small. Besides, relocation would suddenly become a non-issue, so they could be kept in flash.

As good as that may sound, I don't really understand how that should work. Wouldn't a pointerless language hold us back in terms of flexibility? What would that add? And with relocation not being an issue you mean that each jump in the bytecode could just be relative to the start of the program, as it would get interpreted by the VM anyway? Couldn't pointers simply work in the same way?

I'm starting to think that it wouldn't be a bad idea to do it this way, to "create" a new programming language that gets compiled to bytecode that is executed within a VM on the calculator, and make a Ti-OS version of this VM as well as a stand-alone "OS"-VM. Only downside of this approach would be that it's not really in any way better to use the OS version then, so that wouldn't become very popular, and we wouldn't have written a new calculator OS but a new calculator programming language...

Any thoughts on this?

[CoBB]

A B_CALL(_whatever) will be just as many bytes in your program code as a call _whatever, thanks to the DW, and it'll probably be much slower because the routine at $28 has to do some voodoo magic before it jumps.

But if it wasn't for rst, each OS call would take five bytes instead of three.

So I'm glad Ben pointed out the paging issue But you're right that it could be potentially very useful in the sense that you could put eight often used functions there.

Only seven, since one of them is the interrupt routine.

As good as that may sound, I don't really understand how that should work. Wouldn't a pointerless language hold us back in terms of flexibility?

You can do many things without pointers (by which I rather mean raw and unsupervised pointer arithmetic, not the complete lack of dynamic memory allocation), but if you encounter any limit, a seamless two-way assembly interface would help. And it is a fundamental principle in language design that you can't have it all or you'll get nothing but a big mess. Parallelism and raw pointers are a particularly bad company to each other.

What would that add?

Simplicity in language implementation (both VM and compiler, especially when it comes to optimisation) and more safety.

And with relocation not being an issue you mean that each jump in the bytecode could just be relative to the start of the program, as it would get interpreted by the VM anyway? Couldn't pointers simply work in the same way?

Native code must be manually tinkered with when it is moved around, which is cumbersome at best. You'd have to be an inhumanely disciplined assembly programmer to write code that can run from anywhere, or you'd have to do an insane amount of work with the existing C compilers to achieve the same.

Only downside of this approach would be that it's not really in any way better to use the OS version then, so that wouldn't become very popular, and we wouldn't have written a new calculator OS but a new calculator programming language...

I don't think it would be easy to port in its entirety. For instance, Vera (let's call her by her proper name ) would provide much better memory management (perhaps monopoly over the RAM) and a file system that the VM depends on, and maybe even some low-level events in its interrupt. And consider another perspective: it could be ported to the desktop, and programs written for it could be run without a calculator emulator or ROM image. And such a port would also make source-level debugging possible in our high-level language.

On flash file systems, maybe this is worth a look:
http://www.embedded.com/2000/0012/0012ia2.htm

This isn't much different from what we were discussing, although if you remember, my idea was to store the metadata (filenames, pointers to data, sizes etc.) on a dedicated page; now I'd say it is indeed better to do it this way. Anyway, the similarity is not very surprising, since there are very few possibilities to organise your data when you have to work with write-only storage space.

[Jim e]

So I'm glad Ben pointed out the paging issue But you're right that it could be potentially very useful in the sense that you could put eight often used functions there.

Only seven, since one of them is the interrupt routine.

6, RST 00h is where the cpu starts, and RST 38h is the interrupt.

I suggest commandeering several of them for off page calls. Save a few for user definable routines, say rst 08h simply jumps to a point in ram.

As good as that may sound, I don't really understand how that should work. Wouldn't a pointerless language hold us back in terms of flexibility?

You can do many things without pointers (by which I rather mean raw and unsupervised pointer arithmetic, not the complete lack of dynamic memory allocation), but if you encounter any limit, a seamless two-way assembly interface would help. And it is a fundamental principle in language design that you can't have it all or you'll get nothing but a big mess. Parallelism and raw pointers are a particularly bad company to each other.

I think a pointerless VM language would be a great way to go. For one you can ignore relocation, or even ram paging should the user not have enough addressable ram. It wouldn't require programs to be in ram either.

However, again it is to earlier for such talk.

What you should be considering now is the structure and layout of the memory. What hardwares interfaces should be provided and what rountines are needed.

I'd say a good start would be deciding how big the stack should be and where the os system ram should.

[Timendus]

King Harold, what's your e-mail address? Let me know; see topic starter for mine.

[elfprince13]

has anyone talked to tari yet? he's working on his own operating system and last I heard he was making good progress

Who is that and what are the goals of his project?

Taricorp, or The Tari, he's fairly active on Cemetech and UTI, and was active on Detached Solutions for a while (don't know if that forum is back up).

as for his project: http://lifos.sourceforge.net

also, for an idea of what he's done thus far; http://lifos.cvs.sourceforge.net/lifos/

[CoBB]

I'd say a good start would be deciding how big the stack should be and where the os system ram should.

The OS doesn’t really need much RAM, at least if we’re talking about the kernel here. We certainly don’t need user or system variables in the TIOS sense, since there’s no maths functionality or UI on this level. All we need besides the stack is a RAM filesystem for persistent storage of frequently changing data. For instance, a maths shell could maintain all its variables in such files, and itself would be an ordinary managed application. And I’d like to repeat my idea from the Vera forums: malloc() could simply mean allocating unnamed files in the same system, and they would be silently discarded if their creating process finishes running.

[Timendus]

Mailinglist has been made, introduction e-mail has been sent