Naive question about Pascal && OSDEV.

[Combuster]

Why would anyone want to use high level features: to make things easier.

Exceptions are no exception, nor are strings

[leledumbo]

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 using a different approach by keeping the structure of rtl. That it, to create os specific directory and implement os specific functions while including system independent routines. Difficult at first, because you have to understand the organization. But when you've found out, you can get almost everything you have in a normal environment (AnsiStrings, Exceptions, Classes, etc) easily.

[Craze Frog]

Why would anyone want to use high level features: to make things easier.

Exceptions are no exception, nor are strings

If making things easier was the primary goal, why write a kernel? Strings in the kernel is just ridicilous. They have nothing to do in there. They don't add any functionality that can't be added more easily (that was your goal, right?) and more securely/safely in userspace.

[Combuster]

Strings in the kernel is just ridicilous. They have nothing to do in there.

Ok, then your OS must be useless to me, since it can't possibly support accessing files by name.

[JJeronimo]

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.

Not exactly. Not if you wanted to implement a JavaScript compiler that produced machine code first, or some kind of interpreter.
As any programming language, it's turing complete. So, the only properties JavaScript lacks for being useful for writing a kernels is: being easy to have language abstractions mapped to machine resources; and having adequate I/O primitives. Both of these can be implemented as library functions, I guess. Perhaps the result would be less than ideal, but you get the point.
All of this is certainly OK if your goals are tied to some particular paradigm or language.

JJ

[Laksen]

Strings in the kernel is just ridicilous. They have nothing to do in there.

Ok, then your OS must be useless to me, since it can't possibly support accessing files by name.

I think we are discussing pascal strings here

Shortstrings are fine and easy to implement in the RTL, but limited to 255 characters. AnsiStrings are even easier for some reason to implement, but you'll find yourself in a mess when stuff like garbage collection comes into play, which it automatically does.

So you, effectively, have no choice but to use either pchars or shortstrings IMO. I tried ansistrings but it didn't work out easily enough. It was nice to have in the kernel but it got pretty messy when I had to interface it to kernel modules or userspace applications

[JJeronimo]

If making things easier was the primary goal, why write a kernel? Strings in the kernel is just ridicilous. They have nothing to do in there. They don't add any functionality that can't be added more easily (that was your goal, right?) and more securely/safely in userspace.

Not exactly. Even if you want everything working with strings to go to user space (e.g. you want to write a microkernel), reporting errors during kernel initialization is certainly useful.

JJ

[Craze Frog]

If making things easier was the primary goal, why write a kernel? Strings in the kernel is just ridicilous. They have nothing to do in there. They don't add any functionality that can't be added more easily (that was your goal, right?) and more securely/safely in userspace.

Not exactly. Even if you want everything working with strings to go to user space (e.g. you want to write a microkernel), reporting errors during kernel initialization is certainly useful.

JJ

array of char can be used for that.

And exceptions relies on stack frames, which on x86 is really debugging information (contrary to popular belief they are not needed for anything else).

[Combuster]

array of char can be used for that.

So a string is not an array of characters?

[JJeronimo]

And exceptions relies on stack frames, which on x86 is really debugging information (contrary to popular belief they are not needed for anything else).

I doubt you cannot implement exceptions in a way that does not rely on stack frames.

JJ

[Laksen]

array of char can be used for that.

So a string is not an array of characters?

Yes, but in Pascal terms you also have some chunks of meta data for each string(length, ref count, type, etc).

PChar is the C equivalent of char*. No language support for operations on those as they are essentially just pointers
ShortString stores the length in the first byte. String can maximally be 255 ASCII chars. Has all typical string operations
AnsiString/WideString is essentially unbounded on length. It's reference counted as the memory is dynamically allocated when you perform string operations on it

Typed arrays of char can ofcourse be used but you can't perform any real operations on them unless you override the operators for it(which isn't a very good solution..). YOu can compare it and you can move it to other string types, but nothing more really..

[Craze Frog]

array of char can be used for that.

So a string is not an array of characters?

No, pascal strings (pascal has a dedicated type called string) use automatic memory management (and also contain meta-information like the length and reference count of the string). Using them would require a "malloc" or similar. Imagine you encounter an error while setting up memory management and want to report it using a string which may require memory allocation... See why I advise against them?

I doubt you cannot implement exceptions in a way that does not rely on stack frames.

That's quite correct. So essentially, if you want to use exceptions you're stuck with a performance bottleneck forever.

[Combuster]

array of char can be used for that.

So a string is not an array of characters?

No, pascal strings (pascal has a dedicated type called string) use automatic memory management (and also contain meta-information like the length and reference count of the string). Using them would require a "malloc" or similar. Imagine you encounter an error while setting up memory management and want to report it using a string which may require memory allocation... See why I advise against them?

No, because you are claiming that people are stupid enough not to realize that dependency when they implement the runtime. Your claim also means that using operator new in C++ kernels is bad because they might get used before the memory allocator has started.

I doubt you cannot implement exceptions in a way that does not rely on stack frames.

That's quite correct. So essentially, if you want to use exceptions you're stuck with a performance bottleneck forever.

longjumps don't rely on a specific stackframe - at least, they don't need to. Also, what's the difference between using exceptions and RAII in terms of performance when you compare that to nested if statements that check every call for a -1 return and do the cleanup manually.

In the end, the same work is done. Only with exceptions, you need less code to do so (and by that, make less errors).



So, I suggest you quit posting nonsense, its getting annoying.

[Craze Frog]

No, pascal strings (pascal has a dedicated type called string) use automatic memory management (and also contain meta-information like the length and reference count of the string). Using them would require a "malloc" or similar. Imagine you encounter an error while setting up memory management and want to report it using a string which may require memory allocation... See why I advise against them?

No, because you are claiming that people are stupid enough not to realize that dependency when they implement the runtime. Your claim also means that using operator new in C++ kernels is bad because they might get used before the memory allocator has started.

The operator new is explicit (under programmer control), while string allocation is implicit (you have no idea when happens) unless you look at the generated assembly code. You may think you're not using strings until after your memory allocation is set up, in that case you need a separate implementation of error reporting functions just for everything before memory allocation, and even so the string heap may be automatically allocated before the any of your own code even gets to run. There is a huge difference here. Pascal is not like C. Pascal strings require compiler support, and how to do the strings under the hood is not defined. Different compilers may chose to allocate the string heap at different points. The compiler may chose to emit code that allocates a string heap before a single line of your own code even gets to run, and still be standards-compliant, thus your code is instantly unsafe for porting once you use strings.

Using new in C++ requires that you write a run-time library for your OS and implement new. This can be done in C++ and thus should work on every compiler.
Using strings in pascal requires you write a compiler-specific run-time library. How this is done depends on the compiler (and may even be impossible). Understand the difference?

In the end, the same work is done.

That's simply not true. Without exceptions you can check for the errors, and then clean up if the error occurs. It doesn't matter much if that is slow because errors shouldn't occur all the time. With exceptions you have an additional performance penalty even when the error doesn't occur. You have to check for the error (as before), and even if everything is correct, you have the performance penalty of the stack frames.

[dr_evil]

array of char can be used for that.

So a string is not an array of characters?

No, pascal strings (pascal has a dedicated type called string) use automatic memory management (and also contain meta-information like the length and reference count of the string). Using them would require a "malloc" or similar.

That's not true. Pascal strings are arrays of char with the first char/byte being the length of the string. Pascal strings aren't reference counted.

You're talking about extensions to the pascal standard in the form of AnsiString, PStrings, etc.. I agree that support for those types of strings is not necessary. Having good support for pascal strings however is useful.