Naive question about Pascal && OSDEV.

[JJeronimo]

I'm currently studying Pascal because I found the language somewhat interesting, and I plan to use it for OSDEV at some point in the future.

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.

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 GPC)?

Anyway, is this usually a problem when trying to code kernels in Pascal?

JJ


[1] "Freestanding" is a term used by the C standard to denote non-hosted environments, you know. In this case, I mean the same thing (code executed in a non-hosted environment), but for Pascal code (although it's not used officially in the context of Pascal).

[leledumbo]

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.

AFAIK it was made that way in order to accomplish a couple of things, namely safety, speed, and ease of use. A single WriteLn statement with a couple of arguments will actually be splitted based on the arguments. For instance:

Code: Select all

WriteLn('string',255,1.5);

will be transformed to:

Code: Select all

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

Let's examine from the point I give:

• 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)?

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)

[Craze Frog]

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).

[JJeronimo]

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

[JJeronimo]

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.

Right. But the compiler just translates WriteLn statements to the right calls inline, or is any additional low level routine needed to select the appropriate procedure?
Anyway, I'll look at the compiler (assembly) output code when the time comes.

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

Right. Thanks. LOL.

JJ

[Craze Frog]

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

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

[JJeronimo]

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.

NAS - Not A Solution
You also get rid of life problems if you commit suicide.
You also don't risk getting AIDS if you don't have sex.

JJ

[Craze Frog]

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

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.

[JJeronimo]

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

That's not that easy as "just going ahead". Like I said, Pascal doesn't support functions/procedures with a variable number of arguments.

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

There's no problem, except that I'd lose a valuable language feature. Still, not using something is not a solution to the problems it poses.
You can write C++ kernel code without using exception handling because you don't know how to write the unwinder. There's no problem, since error return codes have been here for decades. You could have solved your problem. Still, you wouldn't recommend someone not to use exception handling in C++ because writing the unwinder is difficult.

JJ

[Laksen]

No, it's not a problem once you figure out how they work. I've written my own RTL for my kernel and used the one that come with the compiler for my applications. It's not a problem.

It might be a problem if you are too worried about principles and purity. The best syntax of FPC is very non-standard. Has alot of syntactic sugar and stuff to make your life easier

GPC is a dead compiler. It might work, but it's not really being maintained. So you only have FPC, which is not a bad thing. The Freepascal team works pretty hard on it to extend the language(A freepascal dialect of Object Pascal) and supported platforms. However most of the newer additions are mostly language features and not so much stuff that relies on the RTL

[Craze Frog]

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.

[JJeronimo]

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.

EH is more than a tool to make things easier. It's a way to do more elegant coding.
I think it's a programming paradigm per se. A paradigm that consists on assuming that everything works without problems, while abstracting "abnormal" control flows with the help of the language.
It's undoubtedly a good idea to use EH on a kernel. You are still free not to use it if you really like error codes, or in fact don't want to implement the unwinder, of course. 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.

I guess I just need it. However, I don't share this algorithmic approach to OS coding. Sorry, but I need to dig straight down and understand how things work before believing I control them.
Thanks, anyway. I will take note. (Of course, porting the official FPC rtl may be the eventual preferred solution, specially if that works.)

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

Yes. I will use FPC. I like the idea of using the same language in the kernel and in user mode.

JJ

[Craze Frog]

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

For me that makes sense. Just as if I said I'd use JavaScript for kernel development it would make sense if people told me not to bother. Of course that's more extreme, but the line has to be drawn somewhere.

[dr_evil]

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.

Uhm... It depends on your kernel.

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.

And to make it clear: You don't have to recompile Freepascal for this to work. Even if you create your own RTL - you don't have to recompile FPC.

[Craze Frog]

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.

I'm doing this as well. (Why anyone would want string handling in their kernel is beyond me.)