a programming language "kindof" designed for OS De

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
User avatar
Candy
Member
Member
Posts: 3882
Joined: Tue Oct 17, 2006 11:33 pm
Location: Eindhoven

Re:a programming language "kindof" designed for OS

Post by Candy »

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)
JJeronimo
Member
Member
Posts: 202
Joined: Wed Oct 18, 2006 3:29 pm

Post by JJeronimo »

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
m
Member
Member
Posts: 67
Joined: Sat Nov 25, 2006 6:33 am
Location: PRC

Post by m »

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. :wink:
JJeronimo
Member
Member
Posts: 202
Joined: Wed Oct 18, 2006 3:29 pm

Post by JJeronimo »

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. :wink:
You could still learn more about CPUs cause you would need to write the mode-switching functions... They wouldn't be built-in...

JJ
Post Reply