OSDev.org

kernel64 wrote:

NoItAll wrote: What about turbo pascal or freepascal ?

Not sure, haven't researched those. GNU Pascal is the most capable and most suitable as far as I know. GNU Pascal also uses the C calling conventions, and can call varargs C functions. It also supports inline assembler.

You can for example, ( by add "uses Crt;") use most of turbo pascals function as normal, you will need a exe loader to load your OS.
As for freepascal, here is a freepascal OS
http://www.dex4u.com/pascal/AnonymOS.zip

kernel64 wrote:

NoItAll wrote: What about turbo pascal or freepascal ?

Not sure, haven't researched those. GNU Pascal is the most capable and most suitable as far as I know. GNU Pascal also uses the C calling conventions, and can call varargs C functions. It also supports inline assembler.

I code my kernel by using a small, hand-written RTL with Free Pascal. http://sourceforge.net/projects/glider-kernel It's in the CVS repository under multiboot-i386.

I stated my preferences for Pascal often enough. For example, before I left home at the end of June I was beginning to code something comparable to the C++ Standard Template Library for my kernel, a set of classes implementing the various common data structures I need (trees and lists mostly).

Have to go now, lunchtime. Will be home in 2 weeks.

mystran wrote: What would I need to change in say Python, Visual Basic or Prolog to be able to program an OS with it?

I think... If one would want to write an OS with high level/interpreted only/both languages like python, visual basic or prolog, they should be completely refitted.

If you are thinking it seriously, they should be refitted so that they allows you to compile them to machine native code, while retaining the most important capabilities of theirs. Important capabilities like interpretability.

Actually, I recently started reading OsFaq wiki and intel manuals because of project which slightly goes trough this topic. My first step in the project would be to write backbone for x86 instruction assembler in FORTH. One which allows me to compile forth code for both Real- and ProtectedMode. It'd allow me to write all the code in forth, making assembly languages like NASM, FASL and GAS obsolete for OS programming.

My reasons for picking up forth:

• Very simple design, implementation is so simple that you could possibly stuff it into 510 bytes.(not necessary thought)
• Flexible, while forth is very good on hardware level programming, it has the ability to program itself and extend to much higher level than... for example java is.
• Interpretability, forth is fully interpretable, therefore allowing completely different style of programming to be used after it has been embedded into kernel.
• Reliability, the upper characteristics casts very high reliability as the side-effect, because you can test the code completely in the fly and know exactly what it does, you can be sure the code really works when you leave it and start building on it.

There are consequences as well, which I don't yet know so well. The most well known bad thing about forth is that very few people actually knows anything about it, and even fewer knows how to program with it. Because important components aren't lines but words, people may encounter some difficulties in learning it.

From forth syntax, I can possibly also continue to even more abstract syntaxes, like LISP, which I again can use to represent AST trees and build any language I want on top of it.

I was thinking a couple of years ago of making a simple kernel based on brainfuck. It does, after all, offer nice flat memory access, and it is Turing-complete. With an assembly bootloader and bf interpreter, all subsequent kernel-mode programs could be written in bf.

You could assume that, say, interpreter memory locations 0 to 255 would resolve to I/O ports; A C standard library would reside above that, probably above 1MB. The kernel would automatically resolve library calls, perform stack relocations to real addresses (i.e. not interpreter-space addresses), etc., at a program's load time.

...and all of a sudden BFOS didn't seem like such a bad idea. My point is that any Turing-complete language is theoretically suitable for OS development (but a language suited to OS dev may not be Turing-complete).

EliAtCamp wrote: I code my kernel by using a small, hand-written RTL with Free Pascal. http://sourceforge.net/projects/glider-kernel It's in the CVS repository under multiboot-i386.

I stated my preferences for Pascal often enough. For example, before I left home at the end of June I was beginning to code something comparable to the C++ Standard Template Library for my kernel, a set of classes implementing the various common data structures I need (trees and lists mostly).

Looks good! Thanks for pointing this out.

Part of the issue rests on how much of the system you are willing to relegate to assembly language. There are operating systems (UCSD Pascal, Smalltalk-80 and JavaOS being the canonical examples) in which the operating system runs on top of a lower-level virtual machine interpreter (historically written in assembly, though the JVM is of course in C); taking that approach, you could then use virtually any language you wished for implementing the operating system proper. However, this means that most of what an OS developer would usually consider the kernel is actually in the interpreter. While it can be a useful approach - and certainly amenable to portability, and the actual interpreter-kernel can be quite small indeed - it defeats the purpose of having a system language in the sense of something like C.

For actually implementing the low-level kernel, I would say that compilation into native code is an absolute requirement. While one could implement the rest of the system in another language, the absolute core of the OS needs to actually run on the target CPU.

Also, as a practical matter, it needs to be able to run with as minimal an initial system image as possible (though of course minimal is relative, especially compared to behemoths like Windows and Linux).

Finally, the section which runs before the memory manager is established has to be able to run without any significant dynamic memory allocation of any kind, as does the memory manager itself: while it's true that while booting you have (as one OS writer put it) the whole of the memory to yourself, you also have to know where you are putting things in order to keep track of them. This includes stack allocation; too heavy use of the stack risks crashing the system. Now, that part isn't as disastrous for Lispy languages as it sounds, since tail call optimization is fairly easy for them and iterative forms can be used as well; however, the limits on heap allocation are a serious problem, and stack allocation is generally a poor fit to languages which use lists heavily.

An easy thing to do so that the memory manager has space to run in is to allocate that space out of the kernel binary's BSS section. Viola, GRUB hands you the [1,2,3,4] meg(s) you need to manage all of memory!