You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Many systems have their primary high-level programming language: C on Unix, Objective-C on NeXTSTEP/iOS, Java on Android, C# on Windows Phone. I think DCPU-16 may have one, and for me the best PL would be B.
Why B?
Typeless: everything is a machine word, just like in DCPU-16 assembly.
You don't have to include lots of useless functions, variables and other stuff, you can use extern to include specific things.
It's easy to learn for C and C derivative programmers.
Problems with B.
There's no difference between signed and unsigned numbers.
Possible additions to B.
Inline assembly.
Inline functions/macros.
Inline register access functions written in inline assembly (indirect, like div(dividend, divisor, *excess) - for direct access, use inline assembly).
Inline signed/unsigned functions written in inline assembly.
Some inline functions.
putchar(char, color) // Color includes blinking
puts(length, color) // String itself starts right after length
My DCPUC ( https://github.com/Blecki/DCPUC ) is very much an implementation of B. It's not complete, nor is it exactly like B, but it works the same way (everything is a word, etc).
What's wrong with simply using C? The programming language is meant to be an abstraction from the architecture, so why do we need things like "everything is just a word"?
Many systems have their primary high-level programming language: C on Unix, Objective-C on NeXTSTEP/iOS, Java on Android, C# on Windows Phone. I think DCPU-16 may have one, and for me the best PL would be B.
Why B?
Problems with B.
Possible additions to B.
Some inline functions.
What do you think?
B reference manual.
The text was updated successfully, but these errors were encountered: