One of my headaches when trying to become the next Linus was the fact that FreePascal stands out on its own. Its 32 and 64 bit. Its multi-arch. Its multi-core(for most part). It produces secure code, well better than C anyways...
but one major feature lacking in FP is the fact that we dont trampoline. 16bit code has to be built under DOS with either tp7 or bp7.It cannot be built with FPC. It CANNOT BE merged or linked or whatever to jump into FP code either.(This would be an assembler hack at best) There is no way to thunk between modes (16->32->64) either. Yes, this is possible and will require some assembler hacking to do correctly.
...But C does it seemlessly. Check the Linux kernel trampoline code. Really its an oddiity that that is there because grub is used and we are autobooted into 32bit mode, in some cases 64. Most BIOSes support EFI booting straight from 64bit mode.C itself seems to follow the fact that systems boot in 16bit mode and the kernel needs to jump into 32 or 64 bit mode post boot. Generally this information is correct. But GRUB does this for us. You can do it in assembler. I have to a point in the past.
What GRUB doesnt do is safely let us thunk back into 16bit mode if we need to.
And maybe Im misunderstanding here, but some hardware would need 16bit access like VRAM mode switching or IDE drive access. At least VBE2 from what Im reading and VBE3 either isnt documented at all, or doesnt use 32bit acess. Well, I cant find the entrypoint by probing, anyhoo. Ive tried.
When doing kernel development this lack of support for either thunking or OS loading creates a nightmare.How do you do a VBE mode switch with no VBE entrypoint if in 32bit or higher mode? Same with IDE access. Sure you can use SATA, IF you can find the controller's ID and access point. AGAIN...IF. Windows utilities do not help for under Linux Linux-based development.
People in the past have found these entry points however, the PCI probe code from Linus seems to be incomplete or missing. I cant piece the code together if I tried. And I have. Even code from other people's work in Pascal in the past. No access and no thunking means a useless kernel.
No graphics
No hard disk access
No cdrom access
NO PCI device probing or access
USB keyboard/mouse are BIOS mapped to standard PS2 interfaces until USB is brought online via PCI bus access.
system timing --dont get me started, even typical CPU speed (probed) results are off on occasion
This is as far as Ive gotten.I had to give up. But theory wise, FreePascal should compete hand in hand with C when it comes to kernel development otherwise.With the exception of course the Pascal itself is a much stronger, no need to harden after, language.