Language Made Just For Developing Kernels

[Solar]

system( "/usr/bin/gcc" );

[NickJohnson]

Actually, TinyCC has a dynamic compiling library included. I'm guessing that's why the OP wanted to port it.

[dotNET]

Dude, you practically, no LITERALLY recreated C, and there's a problem with that.

1) The unorganized mush you call a language would be very hard to maintain, let alone actually reading the syntax!

2) A normal person wouldn't be able to type 100 lines of code and have enough time to sort out the multiple parameter, tabstop, etc. errors in an entire week! My fingers would cramp at the 10th line.

3) Take a blend ofprogramming languages and make it your own. Don't reinvent C. If I could make a kernel dev language, it would be based off of Clarion. If you could design it right, you could have a window definition contour to the end user's GUI window interface (if there is a GUI) and have the original C or ASM coded preset window definition in a seperate included file. Not only would this be helpful for rapid kernel deving, but it would also make a wonderful scripting language.

Here's an example of a window definition.

Code: Select all

MyWin  WINDOW('Example Window') ,AT(,,100,100),SYSTEM
  STRING('Example Code!'),AT(26,23),USE(?TheStringsName)
END

And to actually open it...

Code: Select all

CODE
OPEN(MyWin)
ACCEPT               ! this is a comment - ACCEPT: execute the window stuff!!
! More code here
RETURN      ! exit application
END

Everything else that I didn't comment on should be self explanitory if you can read english.
Questions on Clarion? Anyone? Try googling for the wiki on it: "clarion language - wiki".

[Combuster]

Dude, you practically, no LITERALLY recreated C, and there's a problem with that.

Troll?

[earlz]

Dude, you practically, no LITERALLY recreated C, and there's a problem with that.

1) The unorganized mush you call a language would be very hard to maintain, let alone actually reading the syntax!

2) A normal person wouldn't be able to type 100 lines of code and have enough time to sort out the multiple parameter, tabstop, etc. errors in an entire week! My fingers would cramp at the 10th line.

3) Take a blend ofprogramming languages and make it your own. Don't reinvent C. If I could make a kernel dev language, it would be based off of Clarion. If you could design it right, you could have a window definition contour to the end user's GUI window interface (if there is a GUI) and have the original C or ASM coded preset window definition in a seperate included file. Not only would this be helpful for rapid kernel deving, but it would also make a wonderful scripting language.

Here's an example of a window definition.

Code: Select all

MyWin  WINDOW('Example Window') ,AT(,,100,100),SYSTEM
  STRING('Example Code!'),AT(26,23),USE(?TheStringsName)
END

And to actually open it...

Code: Select all

CODE
OPEN(MyWin)
ACCEPT               ! this is a comment - ACCEPT: execute the window stuff!!
! More code here
RETURN      ! exit application
END

Everything else that I didn't comment on should be self explanitory if you can read english.
Questions on Clarion? Anyone? Try googling for the wiki on it: "clarion language - wiki".

Dude, you practically, No literally recreated COBOL

[Solar]

Dude, you practically, No literally recreated COBOL

[AaronMiller]

lol, well alright then.

Actually, new idea. How about a normal scripting language? I have a cool idea for syntax, that looks like everything else (so I guess it's not a new idea.)

Example: (Entered in command prompt)

Code: Select all

$getSum($a, $b) = { return $a+$b; }
echo $getSum(5, 17)
$myVar = $getSum(40, 2)
echo $myVar.environment // Should output "LOCAL" (part of this command prompt session only)
$myVar.environment = "SYSTEM"
echo $myVar.environment // Should output "SYSTEM" (which is part of the system's set of environment variables)
$name = ""
input "What's your name?\n%s\nCool! Hi $name", @name // Get input, and put it into "name"
$myVar = $name

Basically stuff along those lines I think would be quite useful. I mean, I know bash scripts are pretty powerful, but I don't want my OS to follow after "bash" I want it to be a bit more unique. Although, this does look a bit like PHP I suppose.

Note how functions are made:
$funcname(params) = { expression(s); }

Where as each expression is separated by semicolons. (The semicolon used in the example above was unnecessary.)

Cheers,
-naota

[Daevius]

Hmm, to be honest...scripting languages would be the least to use for anything near critical performance. You use scripting languages when you have non-programmers on your team (model animators or mappers) and hardcoding is too difficult for them or too much work. You also use it when you want instant change of behaviour without the need for the development kit or the compilers.

You can add a scripting language to your OS like Windows has (batches, although they're VERY messy and a pain to work with), but scripting an OS is like building a house with LEGO.

[dotNET]

Whether or not it looks like COBOL, it is still more readable than that other guy's crap. However, a mere window structure is not enough code in order to tell the difference between Clarion and COBOL. You want to see some COBOL? Well here it is:

Code: Select all

MULTIPLY RATE BY THIRM GIVING PAYMENT ROUNDED.

And yet that would be expressed in Clarion as no more than:

Code: Select all

Payment = Rate * Thirm

If anyone is still convinced that this is COBOL, then I can give you the Language Reference, Programmers Guide, Getting Started, Learning Clarion, and the ABC Builder Template Guide manuals at your command. Now, getting back with the original subject, can anyone else provide valuable suggestions on how to improve this OS language?

[AaronMiller]

A "bits" keyword is one of the things that makes it useful for OS development. Some compiler intrinsics like outb, inb, outw, inw, (etc) and a simple to use way of entering assembly and general data would be useful. The "$" bit I don't think is a good idea any longer. It's unnecessary and clutters the code.

Example of a new idea for the syntax:

Code: Select all

kmain() = // Functions can be set fairly easily. If kmain() returned a signed integer, kmain:sint
{
    // bits 32 is unnecessary
#bits 32 // Only takes a constant value, similarly there would also be "align" for optimization purposes
    kernel.textmode.write("Hello World!\n"); // Assuming you have the namespace "textmode" inside the namespace "kernel" with a "write" function it it
#arch x86_64 // Do architecture dependent code
    /*
        Do long mode initializing stuff here
    */
#bits 64
    /*
        Once in 64-bits...
    */
#arch // End architecture dependent code
}

Basic types:
sint/uint = integer with the full number of bits (ex, if on x86 then 32-bits, if on x86_64 then 64-bits)
s8/u8 = signed/unsigned 8 bit integer
s16/u16 = signed/unsigned 16 bit integer
(s32/u32, s64/u64, and perhaps more)
float, double
void

Variables declared like so:
varname:vartype
or
varname // vartype defaults to int"

If the variable is retrieving a block of code (specified with "{" and "}"), then vartype defaults to "void" in which case it's a function pointer which points to the block of code it retrieves. (It's only a pointer when it retrieves a block of code in another function, if it's in the global scope it's just a simple symbol.)

I haven't yet decided how calling conventions should work.

Suggestions/Criticisms?

Cheers,
-naota

[AndrewAPrice]

In my opinion, I'd like to see a systems Python.

[earlz]

In my opinion, I'd like to see a systems Python.

I think I'd rather see a systems Ruby ... I've actually considered trying to write such a thing.. Add in manual memory allocation(that is optional) and remove the eval() (or move it to a library) and it's completely possible if you follow a hybrid static/dynamic compiling.. It's a very *strange* way to compile the way I see it though....

Basically every variable is held in some structure in memory which can be modified, so that you can actually override functions with the eval() keyword and such.. idk.. It would be such a slow systems language though..

[thre3dee]

lol, well alright then.

Actually, new idea. How about a normal scripting language? I have a cool idea for syntax, that looks like everything else (so I guess it's not a new idea.)

Example: (Entered in command prompt)

Code: Select all

$getSum($a, $b) = { return $a+$b; }
echo $getSum(5, 17)
$myVar = $getSum(40, 2)
echo $myVar.environment // Should output "LOCAL" (part of this command prompt session only)
$myVar.environment = "SYSTEM"
echo $myVar.environment // Should output "SYSTEM" (which is part of the system's set of environment variables)
$name = ""
input "What's your name?\n%s\nCool! Hi $name", @name // Get input, and put it into "name"
$myVar = $name

Basically stuff along those lines I think would be quite useful. I mean, I know bash scripts are pretty powerful, but I don't want my OS to follow after "bash" I want it to be a bit more unique. Although, this does look a bit like PHP I suppose.

Note how functions are made:
$funcname(params) = { expression(s); }

Where as each expression is separated by semicolons. (The semicolon used in the example above was unnecessary.)

Cheers,
-naota

You realise that's a lot like PHP. When you "think up" languages, you seem to just grab an existying syntax and change 1% of it. That's not making a new language.

[AaronMiller]

I have a cool idea for syntax, that looks like everything else (so I guess it's not a new idea.)

I think that explained what I meant by it. I haven't seen any system scripting languages that follow that sort of a syntax.

[stephenj]

I'm developing a typed assembly-like language for systems programming. At first, I designed it because I didn't like the way asm(...) works in C/C++. But it kind of grew into a language in it's own right.

My original plan was to develop the asm-like language, and then use that as a target language for a C-like syntax equivalent language. But the more I use the language, the less reasonable it seems. Truthfully, a C-like equivalent seems like a straight jacket at this point.

My views of what an OS dev language should look like have changed over the past year or so, but they are starting to stabilise. The constraint of designing a language that does as much as possible at compile time*, can inspire some creativity. Furthermore, we have a lot of options today that weren't reasonable when C was made (for example, a 1MB binary isn't that much now, at least once you get past real mode). Which does give a 21st century low-level language designer some advantages.

* I've thought about a scripting language that can do JIT compiling within it's binary. Ignoring the memory, security and speed issues, I don't believe such a language would be appropriate for OS development. Most of the OS code I've wrote is just bit twiddling, which can be done just as well (if not better, depending on usage of primitives) in a low-level language. All a scripting language does is get you further from the machine you are trying to manipulate. But I currently believe in using higher-level languages (including scripting languages), once you are no longer talking about OS code.

Aaron, my latest design calls for two keywords similar to what you were thinking, asm and arch. asm is used when I want to write straight assembly, and the exact platform can be specified. arch is when I want to write something for a quality of an platform (for example, something that only big-endian platforms, or x86s, should do). I'm not sure if this solution is perfect (I lack access to anything but an x86 at the moment), but it sounds to be a more generalised form of what you are trying to do. Ifdefs could do the same trick though.