I understand what you mean. By dependencies I meant user space libraries such as glibc and musl.
The language itself is fully self-contained. It initializes itself with nothing but a static array of bytes.
Could be possible to modify lone to run on bare metal instead. Perhaps by replacing the Linux system call code with BIOS I/O functions and replacing the Linux process entry point code with boot code that initializes the CPU and hardware.
>Could be possible to modify lone to run on bare metal instead. Perhaps by replacing the Linux system call code with BIOS I/O functions and replacing the Linux process entry point code with boot code that initializes the CPU and hardware.
Just don't make the mistake golang made. In most systems, the "stable interface to the kernel" isn't the syscall, but the c library.
I understand what you mean. By dependencies I meant user space libraries such as glibc and musl.
The language itself is fully self-contained. It initializes itself with nothing but a static array of bytes.
Could be possible to modify lone to run on bare metal instead. Perhaps by replacing the Linux system call code with BIOS I/O functions and replacing the Linux process entry point code with boot code that initializes the CPU and hardware.
https://wiki.osdev.org/Printing_to_Screen
That would just shift the dependency from Linux to the firmware though.
>Could be possible to modify lone to run on bare metal instead. Perhaps by replacing the Linux system call code with BIOS I/O functions and replacing the Linux process entry point code with boot code that initializes the CPU and hardware.
Just don't make the mistake golang made. In most systems, the "stable interface to the kernel" isn't the syscall, but the c library.
(re: golang on openbsd)
Absolutely. I've written about this topic and how Linux is different:
https://www.matheusmoreira.com/articles/linux-system-calls
My plan is to target Linux exclusively.
2 replies →
> Could be possible to modify lone to run on bare metal instead. Perhaps by replacing the Linux system call code with BIOS I/O functions
Certainly not. Calling BIOS interrupts requires the system to be running in real mode, which is incompatible with running 32-bit code.
>Calling BIOS interrupts requires the system to be running in real mode, which is incompatible with running 32-bit code.
Hold my beer[0].
0. https://en.wikipedia.org/wiki/DOS_Protected_Mode_Interface
2 replies →
I see. Could it work in protected mode? The OSDev wiki page I linked uses that approach to write to video memory.
> Assuming that you are in protected mode and not using the BIOS to write text to screen, you will have write directly to "video" memory.
I have pretty superficial knowledge about OS development so I should probably refrain from speculating further.
1 reply →
My project runs in your imagination so there’s no hardware or electrical dependency other than brainwave activity.