OSDev.org

Jordan3 wrote: hmmm I didn't know that, yea probably should learn everything in the language first lol I still don't know what enumerators are!

[me=Jordan3]changes his un-nifty gdt code[/me]

#define MSLang language(Microsoft)

#define Enumerator MSLang(Iterator)

This thread is really old... but never mind!


I have a suggestion that I think (parhaps) should be useful in a language designed for OS development... the language could support the notion of CPU operating mode...

There should be a standard operating mode... and functions could be declared to override that default, so that the compiler could execute a predefined function *before* calling the function proper...
When defining an operating mode, the language should allow to define not only mode-switching functions, but also to choose the sections where code&data related to that function should be assembled to (in order to adjust the linker script to correctly relocate all the functions, which of course has to do with the nature of the operating mode)...

So, for example, if one needed to mix x86 real mode and protected mode code, RM functions could be called directly from protected mode ones and the switch to real mode (or VM86) would be automatically called...

I've not seriously thought about the real implementation concerns of this, but at a glance looks possible...


JJ

JJeronimo wrote:This thread is really old... but never mind!


I have a suggestion that I think (parhaps) should be useful in a language designed for OS development... the language could support the notion of CPU operating mode...

There should be a standard operating mode... and functions could be declared to override that default, so that the compiler could execute a predefined function *before* calling the function proper...
When defining an operating mode, the language should allow to define not only mode-switching functions, but also to choose the sections where code&data related to that function should be assembled to (in order to adjust the linker script to correctly relocate all the functions, which of course has to do with the nature of the operating mode)...

So, for example, if one needed to mix x86 real mode and protected mode code, RM functions could be called directly from protected mode ones and the switch to real mode (or VM86) would be automatically called...

I've not seriously thought about the real implementation concerns of this, but at a glance looks possible...


JJ

That may bring some convinience anyway...But I think we can alerady achieve that using existing languages(even besides assembly).We can already build libs/procedures to implement that and it dosen't need to be integrated into a new language.

Besides,knowing more about how CPUs work brings me fun...Don't break it.

m wrote:That may bring some convinience anyway...But I think we can alerady achieve that using existing languages(even besides assembly).

The idea is all about convinience!
We can do it with current languages, yes, but it's not so transparent... for example, you cannot just call a function meant to execute in a different mode and have the compiler automatically call the mode-switching function and adjusting assembler directives...

In order to execute x86 BIOS routines, I wrote an entire assembly function that switched bacl to real mode, loaded the processor state from a C structure, executed the int, resaved the processor state and switched back to protected-mode to gracefully return to the caller... That would be greatly simplified and flexibilized if I could separete the actual Real Mode operation from the mode-switching routine...

Besides,knowing more about how CPUs work brings me fun...Don't break it.

You could still learn more about CPUs cause you would need to write the mode-switching functions... They wouldn't be built-in...

JJ