integrate the old

[JazzMazz88]

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.

[Cyrax]

In FPC SVN trunk, there is support for x86 16-bit CPU/OS (MS-DOS, Win16). You can build .COM and .EXE files with it. But I don't know if there is true support for 16-bit flat binaries (tiny, small, large, huge) yet.

[Thaddy]

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

Uhhh, yes they are available either in the FPC sources or as third party.
That goes for ALL of them. Both on Linux and win64 at least.

Even if f.e. a certain hardware abstration isn't there it is still possible to implement. I make one very small exception: under win32 it is hard to write device drivers, but not impossible.

I don't know about Linux specific remarks from you but I guess you haven't noticed that under Linux they are just files?

[marcov]

So how does the thunking work with gcc. Which attributes do you need to pass?

For the rest, yes, bios support for the Dos way has pretty much ended, and you can't create a 16-bits application anymore that works with mostly the BIOS and boot that as the "OS".

The world revolved around the Sun 20 times since dos basically died, and the BIOS support for Dos being phased out is part of that.

Now you must really write an OS and handle all hardware yourself. This is not trivial, which is why the linux kernel is 3MB (heavily compressed!)+tens of MBs of modules, of which typically some 10-15MB are prepackaged in an initrd just to make boot possible on a general PC.

I just don't see what that has to do with FPC.

[Thaddy]

I have an OS written in fpc that can say "hello, w" and then crashes Not my finest hour, but I can give the code to work from. Better look at the embedded stuff. Btw: my code is very old. But I can still bootstrap this on a Raspberry Pi. (It's rather ARM centric, but anyway)