Skip to content
This repository has been archived by the owner on Apr 20, 2024. It is now read-only.

Future Vision #9

Open
minexew opened this issue Jun 19, 2017 · 6 comments
Open

Future Vision #9

minexew opened this issue Jun 19, 2017 · 6 comments

Comments

@minexew
Copy link
Owner

minexew commented Jun 19, 2017

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!

@minexew
Copy link
Owner Author

minexew commented Jun 19, 2017

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.

@nukeop
Copy link

nukeop commented Jun 19, 2017

You're one of those obnoxious India-niggers, aren't you?

@jibanes
Copy link

jibanes commented Jun 30, 2018

or something like plan9port?

@flowac
Copy link

flowac commented Dec 13, 2018

Could we pick a CPU with integrated graphics and offload the drawing the the integrated graphics?
I have experience with firmware and driver development but never did anything like a graphics driver.
Terry said a 7 year release cycle. Maybe we could do what the consoles are doing?
Same CPU with integrated graphics for everyone. That way we only need to make 1 GPU driver.

@minexew
Copy link
Owner Author

minexew commented Dec 13, 2018

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:
god: command not found

@gennaro-arch
Copy link

gennaro-arch commented Apr 22, 2019

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants