OSDev.org

Pascal, as I've seen so far, has quite a lot of pragmatic syntactic sugars for functions and procedures that apparently make part of the "library". This means that the language supports some non-standard syntax for calling them. For example, you can call WriteLn with an arbitrary number of arguments even though you cannot write a Pascal function/procedure which takes a variable number of arguments.

WriteLn('string',255,1.5);

WriteString('string');
WriteInt(255);
WriteReal(1.5);

• safety
  As you can see, the compiler will choose appropriate call for the given argument. Thus, you don't have to make sure that you're calling the right function. Most Pascal compilers won't let you do it wrong anyway, the strong typing behavior will prevent you.
• speed
  Unlike (sorry, C programmers ) printf, which parses input (without checking! ) while printing at runtime, these calls will only do printing. No parsing and checking needed as it's done at compile time.
• ease of use
  If you've ever programmed in Modula-N or Oberon, you might be peevish to type each part yourself. Since Prof. Wirth purpose with those two is to reduce built-in runtime support (basically, everything that's built-in) and replace it in a library instead, this is needed. Pascal (until today) still prefer the ease of use, and still it can prove that a language with many built-in runtime support can still be used even to write a kernel.

While I know that it's perfectly possible for the compiler to implement this non-standard syntax in a freestanding-friendly[1] way, I also understand that it's very easy to fall into a bunch of library dependencies, thus making the language more difficult to use in freestanding environments. Is this the case of modern Pascal compilers (namely FPC and GPF)?

Craze Frog wrote:Note that it's exactly the same as C, really: you can't use functions and procedures that are dependent on the operating system unless you rewrite them so they are dependent on your operating system. Once you put anything but your own units in the uses clause you're on thin ice, and also you have to rewrite the system unit (or replace it with an empty unit, but then things like writeln() won't work).

leledumbo wrote:

While I know that it's perfectly possible for the compiler to implement this non-standard syntax in a freestanding-friendly[1] way, I also understand that it's very easy to fall into a bunch of library dependencies, thus making the language more difficult to use in freestanding environments. Is this the case of modern Pascal compilers (namely FPC and GPF)?

From my experience, half true. First, there's no library dependencies except the RTL itself. Second, you need to know how it's handled internally. The latter is the one most people can't get right immediately. My kernel can't yet use it, but I already know what to do. You can implement replacer function as in the wiki instead.

P.S.: A little typo there: GPC (GNU Pascal Compiler), not GPF (General Protection Fault)

JJeronimo wrote:

Craze Frog wrote:Note that it's exactly the same as C, really: you can't use functions and procedures that are dependent on the operating system unless you rewrite them so they are dependent on your operating system. Once you put anything but your own units in the uses clause you're on thin ice, and also you have to rewrite the system unit (or replace it with an empty unit, but then things like writeln() won't work).

The problem(?) is that strictly speaking WriteLn in not a procedure. It just happens that it's special syntax looks like the procedure calling syntax.

JJ

Craze Frog wrote:

JJeronimo wrote:The problem(?) is that strictly speaking WriteLn in not a procedure. It just happens that it's special syntax looks like the procedure calling syntax.

It's not much of a problem if you don't use it.

You also don't risk getting AIDS if you don't have sex.

Craze Frog wrote:If you want to get your hands dirty, just go ahead and do the WriteLn(), then.

I don't see a problem with doing output with normal functions from the kernel.

Still, you wouldn't recommend someone not to use exception handling in C++ because writing the unwinder is difficult.

That's not that easy as "just going ahead".

Craze Frog wrote:

Still, you wouldn't recommend someone not to use exception handling in C++ because writing the unwinder is difficult.

Actually, I would. If writing the tool to make things easier is harder than writing the program itself, I'd say just go ahead and write the program.

That's not that easy as "just going ahead".

Download the source to freepascal. It contains a folder called rtl. Inside that is platform specific code (organized in folders). You need to replace some of that code with your own.

Laksen wrote:GPC is a dead compiler. It might work, but it's not really being maintained.

But saying "bah! don't use it" to someone who told you he wanted to use EH in the kernel doesn't make sense.

That's not that easy as "just going ahead".

Download the source to freepascal. It contains a folder called rtl. Inside that is platform specific code (organized in folders). You need to replace some of that code with your own.

The alternative is to create a unit called "system" (system.pp in the same directory). Then you can compile your code which doesn't have any dependencies. The advantage is that you don't have to bother with RTL just to start. The downside is that almost nothing works (64bit variables, writeln, string-handling is limited, ...) and you have to write a memory allocator yourself. But I'm using this approach for my microkernel.