Hello,
Continuing on the questions about KnightOS, I have pretty much decided that programs must be position independent. This means that call and jp would not work (remind me if there is more I'm forgetting). However, I think I have a solution. It comes in the form of kcall and kjp. These would be similar to bcall in that they would be rst commands disguised as macros. It would pop the old address off the stack, decrement it a few, and push it back (essentially executing the same instruction again). Then, it would add the address requested to the offset from the start of the program. After doing so, it would return to the program. This way, the addresses are corrected, and it only ever has to do it once per jump/call, and rets are already taken care of.
Thoughts?

I'm not entirely sure what you mean.. something like this?

Code:

It would work, but you hit the problem of time. All that processing for a simple jump will really kill timing-sensitive things (the kcall would be even slower than this example since that requires a bit more trickery on the stack).

My approach to this problem has been some sort of dynamic linking, either with a table of absolute jumps to replace or a very clever not-quite-disassembler which can follow control flow, seeking out some construct indicating an absolute jump to be modified at link-time. I think it's well worth the effort to do the dynamic linking, since the time hit you take while loading is going to be much less important than while a program is running.

SirCmpwn, Tari, this has been explored many times before (as Tari mentions), and every solution so far designed either is memory-hungry (such as the offset table of relocatable addresses) or CPU hungry (like the implementation that you just came up with). Since the calculator is such a constrained platform compared to web programming or computer programming, wherein you have almost no hardware differences between devices other than more ROM, a processor faster by a known amount, or the presence or absence of a USB port, I personally think one doesn't lose flexibility by making code location-dependent. So many speed tricks are possible with such a small code footprint.

It would be quite slow, but only done once. For instance, the OS would see this loop:


Code:


and turn it into this loop as soon as kjp was called:


Code:


Same with call. The program would never move once it starts executing.

If you modify the program in-place you lose the possibility for easy program data writeback and allowing programs to fill all of RAM.
Unless you make a note of every time you do such a replacement, you need to discard the modified binary when execution completes, meaning you're forced to keep an unmodified copy of it around somewhere (well, you could do something odd with a couple scratch bytes inline to hold the offset, but it's a hackish thought at best).

Well, if you're making a new binary format to be location independent, you could add separate code and data sections like ELF does. Then you can still support write backs to an extent.

I don't know about making it hard to fill the RAM, but writeback should not be supported anyway, with how I'm working the filesystem. It uses a full fledged filesystem, and I encourage programmers to use save files and such.

Indeed. As an example of something that was used on Z80 systems there's REL which is relatively compact. (BBC BASIC was supplied to me as REL files, which I then relocated to the TI-specific app addresses).