-
Notifications
You must be signed in to change notification settings - Fork 79
Future Vision #9
Comments
On second thought, if we go with Linux, TOS shouldn't run in userspace,but rathrer be loaded right into the kernel. We could use AOT (unholy+GCC) to bootstrap (TOS kernel as well as programs), and eventually implement JIT for the supported platforms. This applies to x86 as well as ARM. |
You're one of those obnoxious India-niggers, aren't you? |
or something like plan9port? |
Could we pick a CPU with integrated graphics and offload the drawing the the integrated graphics? |
Hardware graphics is so much more complicated. I feel like it goes completely against the spirit of TempleOS. After all, why would you need to accelerate 640x480x16? God says: |
Well if x86_64 is an architecture of the past we could write the OS for quantum computers... There are so many online simulators and IBM allows you to use a quantum computer remotely. It could be very useful in this case since an OS for a quantum computer needs a minimal GUI and system and low resolutions like these and would be an excellent operating system to control and program quantum computers since it is designed to offer an environment for programming (as well as being a temple of course). I don't know about you but I see it. Also because it seems to me ugly to throw away all the work done in most of his life and I believe that in this way it could become very useful. |
x86_64 is an arch of the past, and to keep things fun and interesting, we'll have to try something new.
RPi is pretty big right now, but implementing our own hardware support is unrealistic. We could either look at some of the other hobby OS kernel projects (though those are mostly x86-focused) or make use of Linux.
Other possibilities include going with something x86-based, but leveraging existing hardware support. TempleOS can't sit on top of Linux directly, because it handles registers and context switching differently. This also precludes Wine-like user-mode binary loaders (we certainly tried!).
Perhaps the compiler could abstract this even in existing codebase. TempleOS would then run as a single Linux process, managing its Tasks similar to how co-routines are implemented in C. Other kernel routines (disk, video, input) would be reimplemented by means of Linux syscalls. Either way, it would be no small undertaking.
At the very least, this implies we'll need a new compiler. JIT is a serious challenge, but also a big part of what makes this OS so unique, so it should be kept at all cost.
God says:
ahh, fuck it!
The text was updated successfully, but these errors were encountered: