Does anybody learn C any more?

[brucehoult]

If I was writing a compiler for a limited machine such as the 8051

There are three memory models

• small: the total RAM is of 128 bytes, all variables and parameter-passing segments will be placed in the 8051's internal memory.
• Compact: the total RAM is of 256 bytes off-chip, 128 or 256 bytes on-chip, variables are stored in paged memory addressed by ports 0 and 2. Indirect addressing opcodes are used. On-chip registers are still used for locals and parameters.
• Large: the total RAM up to 64KB (full 16bit access, physically multiplexed), 128 or 256 bytes on-chip, variables etc. are placed in external memory addressed by @DPTR. On-chip registers are still used for locals and parameters.

I would have thought the last sentence in the paragraph you just quoted the first part of would have indicated that I was aware of what you just wrote?

"On the 8051 you'll obviously need external RAM to run reasonable sized C programs, and will use DPTR to save "register" contents to a large stack there at the start of a non-leaf function, and restore them at the end."

[Vtile]

I really don't like it in sense that {} are PITA to write out of my local keyboard (I would need to have US/UK keyboard for just C ) and the case sensitivity is just plain stupid.

The use of braces {} and the case sensitivity is a direct consequence of the early enthusiasm with which the developers at the time adopted the newly arrived ASCII code, replacing the Baudot code.

The Baudot code was case insensitive and only had parenthesis.

Notice that the same thing happens to Unix and its derivatives: all case sensitive and using all those new graphic symbols.

Thanks I did have forgotten this Baudot code existence. I also assume that you do mean the 7-bit ASCII and not this 8-bit ASCII rubbish.

The machine do not eventually not know which kind of hieroglyph you did use for instruction of the functionality, the case sensitivity is only justified for the limited memory of early systems (to process long strings) and to make a hack-jobs even quIckeR. This naturally is only my opinion.

[brucehoult]

If I was writing a compiler for a limited machine such as the 8051 or 6502 or things of that ilk (8080/z80 too) I would allocate 32 ints worth of global memory as RISC-style registers (preferably addressable using 8 bit or smaller addresses in each instruction e.g. 6502 "zero page"), assigned in a similar way to Aarch65 or RISC-V registers (arguments / temps / saved).

Having consumed all the available RAM for that purpose what would be your next step? 

How do you come to equate "32 ints" (i.e. 64 bytes) with "all the available RAM?

Very few 6502 computers were sold with less than 16 KB of RAM, and the vast majority with 48 KB or 64 KB (e.g. "Commodore 64")

The 8051 supports 64 KB of external RAM. You're not going to be successful compiling reasonable-sized C programs for the 128 or 256 bytes of internal memory no matter what your code generation scheme is.

[Vtile]

Besides Begin and End is as much stupidity as is {} in typing sense

I have implemented a lib_tokenizer(1), it handles them as "token". The only thing I can say is ... well "{" consumes less cycles than "begin", simply because it's a shorter string 

(1) long story on the reason. It's parametric and the same code can be reused to serve a shell as well as an interpreter as well as a compiler. It's implemented as library, before using it, you need to define and pass a "dictionary", telling the library about the token (is it an operator? separator? special?), and you can also pass callbacks (pointers to functions) for special cases, e.g. this library is able to "learn" how to recognize a floating point notation, and treats it as token.

That is just how RPL / Forth can be twisted around.

I did once do something similar and replaced some reserved keyword in Codesys-environment [Structured Text (Pascal / Ada derivative)] and with the constant declaration IIRC, I was actually surprised that there were such an "hole" left to it (because of the ST-language IEC definition is all about safety and clarity).

[coppice]

If I was writing a compiler for a limited machine such as the 8051 or 6502 or things of that ilk (8080/z80 too) I would allocate 32 ints worth of global memory as RISC-style registers (preferably addressable using 8 bit or smaller addresses in each instruction e.g. 6502 "zero page"), assigned in a similar way to Aarch65 or RISC-V registers (arguments / temps / saved).

Having consumed all the available RAM for that purpose what would be your next step? 

How do you come to equate "32 ints" (i.e. 64 bytes) with "all the available RAM?
The 8051 supports 64 KB of external RAM. You're not going to be successful compiling reasonable-sized C programs for the 128 or 256 bytes of internal memory no matter what your code generation scheme is.

I exaggerated a little, but if you are serious about making a useful compiler for the 8051 you have to be tight about RAM usage. Half your RAM for working memory, some space for saving in ISRs, and you don't have much left. Many fairly complex programs need only a handful of variables. There are compilers for the 8051 which do a pretty good job of compiling C for applications like that, and have all variables sit in the 128 byte RAM area.

Nobody makes 8051 based devices with 64k of RAM. Some of the 8051 based USB peripheral controllers probably have the most RAM of any class of 8051 based devices. However, most recent 8051 based devices have maybe 1k to 4k of RAM. That gives you some room to move, but you still need to be tight about your RAM usage.

[Berni]

You do forget that even the all mighty C is bootstrapped, propably with Assembler or maybe even with direct machine code.

... And someone mentioned my path from pascal to C. This is not the case, I would think it were more of Ms-Dos batch scripts with 4Dos extensions which did allow crude dynamic graphics, then QBasic. But there were no internet and no general languages (at that PC access). Besides Begin and End is as much stupidity as is {} in typing sense, for clarity I do prefer them because there is more contrast, both sucks though.

I would prefer some (still not invented) hybrid general purpose language which would use parts from visual (ie. Grafcet) to all the way down to machine code.

Edit. GrafSet -> GrafCet .. because French origin .... PS. This mentioned general purpose hybrid language would be called Monkey.

C can bootstrap itself just fine.

Yes you do need bootstraping code when working in raw C to set up everything before it enters main(). But unlike a lot of languages this bootstraping code can be put inside of in a *.c file and put trough the compiler together with all the rest of the code. The only thing that makes that code special is that the linker is told to place that code at the reset vector of the final program so that when execution starts the CPU starts running at the beginning of the bootstrap code.

That being said, usually a least a part of the startup code tends to be written in assembly (Using C before its environment is properly set up makes it very touchy about certain things, so its more reliable to do it this way) but due to the low level way C works it lives in synergy with assembler rather than being above it. The compiler will happily insert a block of assembler code anywhere in the middle of a C program if you ask it for that. It will happily call assembler subroutines the same way it calls any other C function and assembler subroutines can call any C function they like, including any C libraries. This free mixing of C and assembler code is not just there to DIY bootstrap it as some hack or something, its a intended feature of C and is commonly used for hand optimizing critical parts of code. This sprinkling of assembler code is also used for writing operating systems in C, as it lets it do some funky unusual things to a program such as save and restore execution state in order to create a multitasking scheduler and similar OSy things.

This is why C does not need any external bootstrapping to get it going, it is its own bootstrap.

[Vtile]

You do forget that even the all mighty C is bootstrapped, propably with Assembler or maybe even with direct machine code.

... And someone mentioned my path from pascal to C. This is not the case, I would think it were more of Ms-Dos batch scripts with 4Dos extensions which did allow crude dynamic graphics, then QBasic. But there were no internet and no general languages (at that PC access). Besides Begin and End is as much stupidity as is {} in typing sense, for clarity I do prefer them because there is more contrast, both sucks though.

I would prefer some (still not invented) hybrid general purpose language which would use parts from visual (ie. Grafcet) to all the way down to machine code.

Edit. GrafSet -> GrafCet .. because French origin .... PS. This mentioned general purpose hybrid language would be called Monkey.

C can bootstrap itself just fine.

Yes you do need bootstraping code when working in raw C to set up everything before it enters main(). But unlike a lot of languages this bootstraping code can be put inside of in a *.c file and put trough the compiler together with all the rest of the code. The only thing that makes that code special is that the linker is told to place that code at the reset vector of the final program so that when execution starts the CPU starts running at the beginning of the bootstrap code.

That being said, usually a least a part of the startup code tends to be written in assembly (Using C before its environment is properly set up makes it very touchy about certain things, so its more reliable to do it this way) but due to the low level way C works it lives in synergy with assembler rather than being above it. The compiler will happily insert a block of assembler code anywhere in the middle of a C program if you ask it for that. It will happily call assembler subroutines the same way it calls any other C function and assembler subroutines can call any C function they like, including any C libraries. This free mixing of C and assembler code is not just there to DIY bootstrap it as some hack or something, its a intended feature of C and is commonly used for hand optimizing critical parts of code. This sprinkling of assembler code is also used for writing operating systems in C, as it lets it do some funky unusual things to a program such as save and restore execution state in order to create a multitasking scheduler and similar OSy things.

This is why C does not need any external bootstrapping to get it going, it is its own bootstrap.

My point were that and did answered to that when code monkeys at Bell labs did wrote the first C-compiler they did bootstrap it or wrote it (to solve causality dilemma) with existing language. Just like if you do make a lathe, the axels are not made with lathe because a such tool doesn't exist.

That Freepascal as far as I know is independent just like you describe for which ever C is at your example or use some inline assembly code here and there.

Programming languages are merely a tools (for fools).

[Berni]

My point were that and did answered to that when code monkeys at Bell labs did wrote the first C-compiler they did bootstrap it or wrote it (to solve causality dilemma) with existing language. Just like if you do make a lathe, the axels are not made with lathe because a such tool doesn't exist.

That Freepascal as far as I know is independent just like you describe for which ever C is at your example or use some inline assembly code here and there.

Programming languages are merely a tools (for fools).

Sorry i was talking more about the startup of a C program. Where a C program requires its execution environment(stack,globals,heap...) to be set up by the startup script before the actual C code is run. This startup script that bootstraps the actual compiled C code into execution can itself be written in C code so that the first instruction executed by the CPU is actually coming from C code and is used to start execution of the actual C code you wanted to run.

As for how the first working C compiler came into existence when there was no C compiler to compile it. well... it depends a bit on how you look at it. The way it happened is this:
1) A compiler for a weird cut down primordial version of C was written in NB (newB that was written in assembler) and compiled to machine code so it could be executed
2) This compiler was then fed the "weird primordial C" source code of itself and as a result generated an assembler translation of that source code
3) This compiled assembler source code was then fed trough a assembler to turn it into machine code
4) We now have machine code that can compile itself by looping back to step 2

Once this was working the cycle from 2 3 4 is repeated in small steps, each step adding more features to C. Some steps supporting multiple syntaxes for the same thing so that a new syntax could be introduced but still compile with the old compiler, once the new syntax was in the compiler the old one could be deprecated once all traces of it are removed from the source code. After enough of these steps you eventually get to something that would be considered real C code and will compile on modern compilers such as gcc (That first source code from step 1 won't successfully compile on any of our existing C compilers because its too different from C that any of the todays compilers can understand). So one way to interpret this is "The first C compiler was written in a beta version of C"

But yes if you go down the chain the beta version of C had to be compiled first in NB. But NB had to be compiled from assembly code. But to compile the assembly code there had to be a assembler program, and this assembly program had to at some point have been loaded into memory using switches, said switched being toggled by a human directly or a from a set of holes in tape that that some point got punched out by a human. So from that view even assembler needed to be bootstrapped by the ultimate bootstrapping tool, a human flipping bits in memory.

EDIT: Oh and the first assembler program ever run on a given system was likely not written entirely in machine code toggled into memory by hand. But instead the engineer likely used another already working computer to compile it and then just transfer the machine code into its memory. Or if they didn't have a already working computer at there disposal they would manually toggle in a small tool into memory to make a crude "hex editor" so that they could easily manipulate memory and execute it using the computer itself. Perhaps using the hex editor to add some features to the hex editor itself and once that was usable enough start writing the assembler program using the hex editor. The result would likely be a crappy dumb assembler program that would end up being used to write a smarter better version of itself.

[Vtile]

Well machine language is waiting at the ROM registers (or which ever non volatile array of bits) to be called about, put there by the designer(s) of the CPU and that pointing is done with assembly mnemonics (if computer is available), isn't that the case. That is the reason the assembly mnemonic sets differ from CPU to CPU (or uCU).

Isn't the C many times described something like machine independent assembler or something like those lines. Anyhow it is close to assembly with its original form (ansi-C) with only minimal of complex structures (datatypes, branching etc.) what I can remember.  I still don't like the case sensitivity, {} and the religious twist around it.

- JMP for life!

[Kleinstein]

The early K&R C was more cryptic than modern ANSI-C.  I consider there steps from early ANSI C to C-99 or other modern versions (not C++ and the like) are relatively small compared to this.
Especially the early K&R C  is in many aspects relatively close to the machine and by some not really considered a higher level languish.  It is still quite a bit more than the usual assembler - especially as the early assembler versions had less features, like macros.

There is also quite a bit going on in the preprocessed  (all the defines), so it is not just the compiler. The early pre-processor may be borrowed from an assembler or other languish.

[SiliconWizard]

The early K&R C was more cryptic than modern ANSI-C. 

Well, certainly, early, non-standardized C was very preliminary, even though the main ideas were all there. You shouldn't have to deal with it unless you're looking at VERY old source code.

[rstofer]

Code: [Select]

#include <stdio.h>

int foo(i)
int i;
{
    return i+1;
}

void main()
{
    int j;

    j = foo(14);
    printf("%d\r\n",j);
}
[/font]

You might run into K&R syntax using the cc compiler included with 2.11BSD Unix running on a PiDP11 emulation of the PDP11/70.
Among other things, parameters are defined in the lines following the function definition but before the opening brace.
Parameters can not be 'void' but can be omitted.
The original 'The C Programming Language' book may help.  The ANSI version?  Not so much...

https://obsolescence.wixsite.com/obsolescence/pidp-11

[westfw]

The use of braces {} and the case sensitivity is a direct consequence of the early enthusiasm with which the developers at the time adopted the newly arrived ASCII code, replacing the Baudot code.

The Baudot code was case insensitive and only had parenthesis.

Oh come on.  No one ever wrote programs in Baudot codes; they were pretty much long gone by the time C was being developed.  ASCII came along ~1963, and most computer teleprinters were ascii, ebcdic, or something proprietary.  Programming was done by cards, and keypunches used other codes (but not baudot.)Also, there were 7bit baudot-like codes, used by some newswires.  Because people decided that lowercase was important!

Notice that the same thing happens to Unix and its derivatives: all case sensitive and using all those new graphic symbols.

We could have had the APL character set!
K&R may have been gloating a bit over new terminals and/or printers with more characters than an ASR33 or VT05, but I don't think you can blame it on the introduction of ASCII.

[legacy]

I've just committed to buying a Digital DEC VT525 with its original keyboard from the UK, and the price is a bit high (400 UKP shipped) because the unit is very rare and because the included keyboard is a special one.

It looks like a common ps/2 keyboard, but it has special keys; some are dedicated to the vt-terminal functions, some are a programmable shortcut for  ESC-codes, some still look too weird to me, but even the key-scan is rather rare because it's a true key-scan/type3, while PCs keyboards use type2.

It also seems that years ago, if you wanted a keyboard with a "layout for programmers", you had to specifically find a special keyboard, whereas nowadays, you can cheaply purchase a common  (key-scan/type2) keyboard with the UK or USA layout, and you are set.

Anyway, this keyboard is so special not only because it has a full "layout for programmers", specifically made to support Unix and C (so it has keys like <> \/ | ^ " ' {} &, etc ..), but rather because it allows you to manually enter a key-scan code, and it can also be reprogrammed on the fly.

WOW. Now I can type C things as well as I can reprogram some keys to type letters in Icelandic (oh well, this requires special support on the host side ... something to map into "unicode") 

[bsfeechannel]

Oh come on.  No one ever wrote programs in Baudot codes; they were pretty much long gone by the time C was being developed.

The Baudot code, in several of its incarnations (ITA2, US-TTY, etc.), kept on being used long after the introduction of ASCII and the creation of C.

K&R may have been gloating a bit over new terminals and/or printers with more characters than an ASR33 or VT05, but I don't think you can blame it on the introduction of ASCII.

Never said ASCII was to blame. I said they got enthusiastic about its introduction.

We're lucky that Unicode wasn't around when C was created, otherwise we could be writing C like this:

int main()
🍔
        printf( 👯Hello, world!👯 ) 🤮
💩

[techman-001]

I've just committed to buying a Digital DEC VT525 with its original keyboard from the UK, and the price is a bit high (400 UKP shipped) because the unit is very rare and because the included keyboard is a special one.

Wow! a  VT525m, color me green with envy!

Back in the late 80's we used to fight over the Wyse terminals when I was doing data communications, but we didn't have any Dec terminals, I've never see one up close.

[Berni]

Well there are many ways to skin a cat.

Brackets provide a nice convenient way to enclose something, but non US keyboards don't provide 1 key access to most of them. The only one on my SI keyboard is < while >[]{}() all require a 2 key combination. The ever so common ; is also a 2 keys to get ti and yet its on the end of almost every line of C code. Also the most common bracket type the () is not accessible by 1 key press even on US keyboards. So you get used to holding down the modifier keys quite quickly when programming.

The alternative to brackets is the oldschool "begin" "end" that still lives on today in Verilog and il be honest i hate it. I much rater press a 2 key combo than type it out, also it just makes the code look more cluttered by putting in more words than needed. So far the only bracket alternative i found nice is the Python way where you just tab out the indent and that's it(something you would do in C anyway to make it readable), the idea of using whitespace as a programing character is a bit disturbing but it does work pretty well.

Code: [Select]

def main()
    print('Hello world')

As oposed to

Code: [Select]

function main():integer;
begin
   print('Hello world');
end

As for case sensitivity this is pretty much a standard feature is the majority of languages today. And its for a good reason, there is nothing to gain by letting the user write a variable as MyVar in one spot and then myVar somewhere else and myvar in another spot. It just leads to ugly and harder to read code (Especially when more than 1 people work on the same program). But if you want to have C with no case sensitivity all you have to do is add this to your makefile "tr '[:upper:]' '[:lower:]' < input" to convert your C files to all lower case before feeding it into the compiler.

There is no one right way to do programing syntax, but its generally accepted that brackets and case sensitivity is a good way so lots of languages use it today.

[legacy]

Back in the late 80's we used to fight over the Wyse terminals when I was doing data communications, but we didn't have any Dec terminals, I've never see one up close.

We are in contact with a military installation located in Greenland and managed by the Danish Government. They have some weird equipment there, which needs to be repaired or replaced with something new.

One of this was a portable vt-100 in laptop shape, made by Data General with the commercial name of "Walkabout". The "SX" series was a common 386SX laptop running DOS + Kermit, but their version is not the "SX" but rather something that runs a dedicated OS running a dedicated program with a ROM containing proprietary terminal protocols as well as common GG, DEC vt220 and vt100.

Oh, and once again, the keyboard is better than most modern-day notebooks, it is very light-weight and sturdy, unfortunately, it doesn't come with all the key you need to operate with Unix and to program in C because I think they have never programmed in C on that thing.

We cannot ask questions, so I really don't know what they used it for ?


The only clear thing is: "C and Unix" did change the keyboard layout, on terminals, on general purpose computers, and even on laptops 

[legacy]

We're lucky that Unicode wasn't around when C was created, otherwise we could be writing C like this:

I am not sure about this. Writing in Groelan is very difficult, and ASCII makes it even more difficult because you do not have the proper keys to press when you compose a word. The same applies to Danish and Icelandic, and probably to many more human languages of which I have never experimented directly, but I am 100% sure that arctic polar computers are very happy when you have a Unicode extension in your box.

It applies to emails, notes, things that scientists(1) do daily write to track their studies, while Unix and programming languages are more modeled around the English language.

(1) usually around the artic pole it's full of biologists, marine biologists, geologists, ... and a lot of volcanologists around Iceland.

[legacy]

So you get used to holding down the modifier keys quite quickly when programming.

Yeah! That holy magic key 

On my DOS laptop, the key was managed by the operating system, so I lost it when I used Minix and RiscOS because my keyboard was dumb and the OS didn't care about any extra "modifier key".

The "magic" thing of the VT525 is that its firmware directly handles the modifier-key, and it directly sends out on the serial line the correct ASCII code of the wanted char!

I love it 

e.g.
you press the "modifier key" and the keys "9" and "1" on the numeric pad, and the Vterm sends out "[", while on DOS ... when you press "Alt"(1), "9", "1", and the keyboard sends the corresponding key-scan (which means press-and-released codes) for the pressed keys to keyboard-handler, which is managed by the operating system, which has to interpreter what you have typed and react.


(1) "Alt" was one of the common choices for the modifier key, because PCs keyboards do not have a dedicated key, so several implementations are possible.

[bsfeechannel]

I am not sure about this. Writing in Groelan is very difficult, and ASCII makes it even more difficult because you do not have the proper keys to press when you compose a word. The same applies to Danish and Icelandic, and probably to many more human languages of which I have never experimented directly, but I am 100% sure that arctic polar computers are very happy when you have a Unicode extension in your box.

ASCII was developed for the telecommunications industry. The Bell Labs were a subsidiary of AT&T. So it was only natural that the developers of C and Unix have decided to adopt it. Multics, the father of Unix, was designed as a multitask, time-sharing operating system to be accessed primarily via remote terminals. They intended to sell computing time to subscribers like any other utility.

People outside the US usually complain that their keyboard layouts do not encompass all the printable ASCII characters. But that is not a problem with ASCII.

Many non-US keyboard layouts have all the characters you find in the US standard keyboard, plus their specific ones.

[legacy]

People outside the US usually complain that their keyboard layouts do not encompass all the printable ASCII characters. But that is not a problem with ASCII.

Printable ASCII chars don't have any Chinese chars, Japanese chars, Icelandic chars, Danish chars, etc.



The 7-bit version of the printable ASCII chars have all the English chars, while the 8-bit extesnion introuces a few accented letters.



So, with the Extended ASCII set it's not a problem for French and Italian languages because Printable ASCII chars cover all the accented letters, but other human languages have many more accented and different letters so they have serious problems, and this is a big problem with Word processors unless you introduce Unicode.

Code: [Select]

OrangeBox # myemerge-log sys-libs/ncurses:unicode

So, if you have a Unix system with the basic "sys-libs/curses" (note that it's not "sys-libs/ncurses", the "n" stands for "new-support"), you have a problem if you to type a letter in Icelandic. Anyway, you need to recompile the word processor as well as the system libraries.

If you don't find a char in the Extended ASCII table, well ... without Unicode, you have to "remap" the hiest bank in the ASCII chars set (from 128 to 255) to something can serve you. This worked somehow, but it was prone to chaotical results on different systems.

[legacy]

If you don't find a char in the Extended ASCII table, well ... without Unicode, you have to "remap" the hiest bank in the ASCII chars set (from 128 to 255) to something can serve you.

Specifically, "Code page 861" is the canonical "remapped" code page used to write the Icelandic language.

[Berni]

I see the widespread use of ASCII only a good thing. Means that computers of all sorts can read each others text files.

You don't need a real US keyboard to have access to access all of the standard ASCII characters of 32 to 127. Pretty much all keyboards have keys for it, just that some of them are moved behind modifier keys to make room for the extra characters that language uses. There would be reason to complain if a programing language used the € character for something since its usually not found on keyboards outside of Europe.

Its simply not possible to fit all characters the world might need into ASCII even if you use all of the 255 characters. So for this reason Unicode came around to extend the ASCII set into all these other strange characters and give each one a standardized code so that it would render correctly on any computer. Also there is the convenient UTF-8 encoding that makes Unicode text render just fine except for the characters that are not in ASCII.

The thing that makes no sense if why we have QWERTY, QWERTZ and AZERTY layouts for the letters. It doesn't add any new letters, just moves existing letters around, making keyboards around the world more different from each other for no real benefit.

[Karel]

So, with the Extended ASCII set it's not a problem ...

Not true, it is a big problem. Formally, there's no such thing as "extended ASCII".
Second, there's no reliable way to know which "extended ASCII" set has been used (there are more than 220 different ones).
Using "extended ASCII" is a recipe for disaster.
The only real ASCII set has always the msb set to zero (7 bits only).

https://en.wikipedia.org/wiki/Extended_ASCII