Does anybody learn C any more?

[brucehoult]

In "regular" C, automatic variables are usually allocated on the stack, but one of the hardware limitations in 8051 is that it doesn't have any stack worth speaking of, so another approach is needed.

That's only true on machines that are just *slightly* less limited than the 8051.

Ever since MIPS and SPARC and other RISC processors with 32 registers appeared 35 years ago, along with the advent of ABIs with a good number of both caller-save and callee-save registers and good register allocation algorithms, the vast vast majority of automatic variables never see the stack. Leaf functions (where most of the work is done) usually don't touch the stack at all, and non-leaf functions might use a lot of automatic variables but seldom save more than two or three registers to the stack.

The same is mostly true even with 16 register machines such as 32 bit ARM and 64 bit x86. It *could* have been true with 68k and VAX, but ABIs and register allocation philosophy and algorithms hadn't advanced enough at the time and they just used their quite plentiful registers as a cache for stack-based variables, just as 16 and 32 bit x86 are basically forced to by lack of registers.

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). At function entry I'd copy (in non-leaf functions) only the return address and necessary saved registers to another memory area, managed as a stack. The only access that is necessary there is raw push/pop or an ability to store/load at an offset from a pointer (the same as fields in a struct allocated at a non-static address). On 8080/z80 I'd probably actually use push/pop (or maybe (IX+0xNN) (or IY)), and on 6502 (zp),y addressing from a pseudo stack pointer. 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.

[magic]

I seem to recall that K&R C only allowed passing or returning a struct by value if it was the size of an int (i.e. register) or smaller. e.g. on a 32 bit machine you could have two shorts, or a short and two chars or something like that.

I think it was probably only with the introduction of ANSI C that you could (portably) pass or return larger structs.

That might be the only reasonable explanation of this absurd.

But you usually shouldn't -- if you want to return a struct it's almost always better for the caller to allocate a local variable for the result and then pass a pointer to it as an extra argument. Many other languages in fact do this for you automatically.

C will do it automatically for you if you simply return a struct

[bsfeechannel]

I seem to recall that K&R C only allowed passing or returning a struct by value if it was the size of an int (i.e. register) or smaller. e.g. on a 32 bit machine you could have two shorts, or a short and two chars or something like that.

I think it was probably only with the introduction of ANSI C that you could (portably) pass or return larger structs.

K&RC 1st edition (1978)
There are a number of restrictions on C structures. The essential rules
are that the only operations that you can perform on a structure are take its
address with c, and access one of its members. This implies that structures
may not be assigned to or copied as a unit, and that they can not be passed
to or returned from functions. (These restrictions will be removed in forth-
coming versions.) Pointers to structures do not suffer these limitations,
however, so structures and functions do work together comfortably. Finally,
automatic structures, like automatic arrays, cannot be initialized; only exter-
nal or static structures can.

K&RC 2nd edition (1989)
The only legal operations on a structure are copying it or assigning to it as a
unit, taking its address with &, and accessing its members. Copy and assign-
ment include passing arguments to functions and returning values from func-
tions as well. Structures may not be compared. A structure may be initialized
by a list of constant member values; an automatic structure may also be initial-
ized by an assignment.

Let us investigate structures by writing some functions to manipulate points
and rectangles. There are at least three possible approaches: pass components
separately, pass an entire structure, or pass a pointer to it. Each has its good
points and bad points.

That might be the only reasonable explanation of this absurd.

"C is quirky, flawed, and an enormous success."
                                   -- Dennis Ritchie

[brucehoult]

But you usually shouldn't -- if you want to return a struct it's almost always better for the caller to allocate a local variable for the result and then pass a pointer to it as an extra argument. Many other languages in fact do this for you automatically.

C will do it automatically for you if you simply return a struct

That depends on the C compiler (or the platform ABI if there is a standard one), and the size of the struct.

For example in the standard RISC-V System V Unix ABI structs up to two pointers in size are passed or returned in registers, larger structs are passed by reference.

[brucehoult]

I seem to recall that K&R C only allowed passing or returning a struct by value if it was the size of an int (i.e. register) or smaller. e.g. on a 32 bit machine you could have two shorts, or a short and two chars or something like that.

I think it was probably only with the introduction of ANSI C that you could (portably) pass or return larger structs.

K&RC 1st edition (1978)
There are a number of restrictions on C structures. The essential rules
are that the only operations that you can perform on a structure are take its
address with c, and access one of its members. This implies that structures
may not be assigned to or copied as a unit, and that they can not be passed
to or returned from functions. (These restrictions will be removed in forth-
coming versions.) Pointers to structures do not suffer these limitations,
however, so structures and functions do work together comfortably. Finally,
automatic structures, like automatic arrays, cannot be initialized; only exter-
nal or static structures can.

K&RC 2nd edition (1989)
The only legal operations on a structure are copying it or assigning to it as a
unit, taking its address with &, and accessing its members. Copy and assign-
ment include passing arguments to functions and returning values from func-
tions as well. Structures may not be compared. A structure may be initialized
by a list of constant member values; an automatic structure may also be initial-
ized by an assignment.

Note that the first version of ANSI C was ratified in 1989 (and in 1990 by the ISO).

[Berni]

C is not the only language that developed into a few different "dialects" over the years. Quite a lot of old languages had the same happen to them. For example Verilog had some pretty major features added over the years, things like support for signed numbers (Yes it didn't have that way back)

[magic]

That depends on the C compiler (or the platform ABI if there is a standard one), and the size of the struct.

For example in the standard RISC-V System V Unix ABI structs up two two pointers in size are passed or returned in registers, larger structs are passed by reference.

But look, that's even better than creating an on-stack temporary

I am really not that convinced that returning structs by value in C is actually a bad thing. I mean, it is bad for all the known reasons, but not worse than the alternatives. Bummer that it doesn't work on arrays, but at least we can understand the historic reason.

edit
Under the condition that your compiler is smart enough to elide the copy in the return statement.

[legacy]

I think it was probably only with the introduction of ANSI C that you could (portably) pass or return larger structs. But you usually shouldn't -- if you want to return a struct it's almost always better for the caller to allocate a local variable for the result and then pass a pointer to it as an extra argument. Many other languages in fact do this for you automatically.

With SierraC 68K, the C compiler has no problem at return a large struct since things are already allocated on the stack so the compiler simply has to *adjust* it before the function return.

Code: [Select]

------------------------------------------- caller space
push sizeof(return ans)
push sizeof(parameters vars)
push sizeof(local vars)
jsr (function)
------------------------------------------- called space
pop sizeof(local vars)
pop sizeof(parameters vars)
return
------------------------------------------- caller space
consume (ans)
pop sizeof(ans)

The problem arises with RISC machines, since they try to use registers rather than the stack, and forcing a large struct return would cause a different approach, which is proven to be "less performant" than the "passing-parameters-via-registers" and "returning-ans-via-a-couple-of-register" approach.

Code: [Select]

------------------------------------------- caller space
put parameters into register { 1, 2, 3, 4 }
jsr (function)
------------------------------------------- called space
put ans into register { 1 }
return
------------------------------------------- caller space


[legacy]

This is a rpn-evaluator, developed in 2017.  It's built on a lib_tokenizer, and it checks if an expression is valid before trying to generate the machine code for an "ijvm-modified" machine.

Code: [Select]


# defvar uint32_t a;
# defvar uint32_t b;
# defvar uint32_t c;
# defvar uint32_t d;
# defunc uint32_t Foo(uint32_t b, uint32_t c, uint32_t d);

In this example, it takes the expression "a + Foo( b, c, d )" and it converts into a "stack" of { variables, function-calls, operators }

Code: [Select]

# rpn a+Foo(b,c,d)

[rpn] kind3 3:1 token_StrictAlphaNum, type21
[a] kind3 3:2 token_StrictAlphaNum, type21
[+] kind2 3:3 token_Plus, type67
[Foo] kind3 3:4 token_StrictAlphaNum, type21
[(] kind2 3:5 token_OpenBracket, type84
[b] kind3 3:6 token_StrictAlphaNum, type21
[,] kind2 3:7 token_Comma, type9
[c] kind3 3:8 token_StrictAlphaNum, type21
[,] kind2 3:9 token_Comma, type9
[d] kind3 3:10 token_StrictAlphaNum, type21
[)] kind2 3:11 token_CloseBracket, type85

types analysis: PASSED
yards analysis: PASSED
stack analysis: PASSED

expr="a + Foo ( b , c , d ) " : PASSED
rpn=
{
  0   1 cookie     G0 [a] token_StrictAlphaNum, type21
  4   1 f_cookie   G1 [b] token_StrictAlphaNum, type21
  6   1 f_cookie   G1 [c] token_StrictAlphaNum, type21
  8   1 f_cookie   G1 [d] token_StrictAlphaNum, type21
  2  -2 function   G0 [Foo] token_StrictAlphaNum, type21
  1  -1 operator   G0 [+] token_Plus, type67
}

code gen, machine=ijvm-r2
---------------------------------------------- is_G=0
r1=a
---------------------------------------------- is_G=1
xxxx r2=b, push r2, SP=1
---------------------------------------------- is_G=1
xxxx r3=c, push r3, SP=2
---------------------------------------------- is_G=1
xxxx r4=d, push r4, SP=3
---------------------------------------------- is_G=0
push stack[4]=arg_n 3
push stack[5]=ret_addr
call Foo, SP=6
    accessging arg0 stack[1]
    accessging arg1 stack[2]
    accessging arg2 stack[3]
f_ans: r2=stack[1]
---------------------------------------------- is_G=0
r1=r1 + r2
-----------------------------------
###                        SP=1
###                        PASSED
-----------------------------------

As you can see, the answer returned by the function can be of any size, even a super large struct would be accepted if it passed the "(strong) types check", and at the low level, there is absolutely no performance problem with this approach on linear stack machines, because it's the natural way their hardware operates.

The above come from the description of the "ijvm" (integer java virtual) machine designed by Andrew S. Tanenbaum. I have modified it a bit, but it's still didactic toy, funny and useful for my researching.

[bsfeechannel]

Note that the first version of ANSI C was ratified in 1989 (and in 1990 by the ISO).

Yes. I know. It's written on the book cover.



What I'm trying to show is that, before the standard, structures could not be returned by functions. A return is just a copy. And structures were not allowed to be copied.

After the standard, structures could be copied and, therefore, returned. However, apparently, there was never a limit on the size or depth of the structure, other than that imposed by the implementation.

Arrays and strings could never be directly copied, before or after ANSI, except with the use of functions like memcpy(), strcpy(), etc.

[legacy]

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.

There are severe hw limitation for ISRs. Technically (especially on modern 51-cores, e.g. S390 and S400) you can force the code to be xdata-xcode only (large), but ...

[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? 

[SiliconWizard]

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.

There are severe hw limitation for ISRs. Technically (especially on modern 51-cores, e.g. S390 and S400) you can force the code to be xdata-xcode only (large), but ...

Yes, I remember all that now.
A PITA. But hey, it was workable.

[Vtile]

C deserves credit for being the first portable macro assembler and enabling probably the first portable operating system. It also did away with all those stupid special statements and commands which plague old imperative languages, replacing them with plain functions, written in C. You can implement full C standard library in C, try that with Pascal's writeln. The languages you listed really are DSLs in comparison, I would never call COBOL or FORTRAN a "general purpose" language. Maybe Algol, if it's true what they say about similarities to Pascal, particularly the kinds of Pascal that have been adapted to low-level programming by adding pointers and whatnot.

IDK, FreePascal is programmed with FreePascal.

I have learned and forgot the C in past 10 years. 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.

[coppice]

C deserves credit for being the first portable macro assembler and enabling probably the first portable operating system. It also did away with all those stupid special statements and commands which plague old imperative languages, replacing them with plain functions, written in C. You can implement full C standard library in C, try that with Pascal's writeln. The languages you listed really are DSLs in comparison, I would never call COBOL or FORTRAN a "general purpose" language. Maybe Algol, if it's true what they say about similarities to Pascal, particularly the kinds of Pascal that have been adapted to low-level programming by adding pointers and whatnot.

IDK, FreePascal is programmed with FreePascal.

I have learned and forgot the C in past 10 years. 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 Pascal variants that became widely used are not really Pascal. They were extended to the point where they were more C like, and could actually be used to write their own run time library.

[Vtile]

C deserves credit for being the first portable macro assembler and enabling probably the first portable operating system. It also did away with all those stupid special statements and commands which plague old imperative languages, replacing them with plain functions, written in C. You can implement full C standard library in C, try that with Pascal's writeln. The languages you listed really are DSLs in comparison, I would never call COBOL or FORTRAN a "general purpose" language. Maybe Algol, if it's true what they say about similarities to Pascal, particularly the kinds of Pascal that have been adapted to low-level programming by adding pointers and whatnot.

IDK, FreePascal is programmed with FreePascal.

I have learned and forgot the C in past 10 years. 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 Pascal variants that became widely used are not really Pascal. They were extended to the point where they were more C like, and could actually be used to write their own run time library.

The C as it came out to be known, is widely extended and not really represent the hack-job it first were.  Besides real PROGRAMMERS use boolean logic.

[rstofer]

IDK, FreePascal is programmed with FreePascal.

USCD Pascal was written in UCSD Pascal.  The only machine dependent code, written in assembler language, was the interpreter.  This wasn't a lot of code and it was pretty easy to port to different machines.  Circa '77...  Considering that the Altair 8800 was introduced in '75 (I bought mine in early '76.  I didn't play with UCSD Pascal until '80 bit it was an important step on the way to modern machines.  The IBM PC was introduced in '81.  It was a slug compared to the 6 MHz Z80 machines running CP/M.

[rstofer]

Besides real PROGRAMMERS use boolean logic.

And wire-wrap

[coppice]

C deserves credit for being the first portable macro assembler and enabling probably the first portable operating system. It also did away with all those stupid special statements and commands which plague old imperative languages, replacing them with plain functions, written in C. You can implement full C standard library in C, try that with Pascal's writeln. The languages you listed really are DSLs in comparison, I would never call COBOL or FORTRAN a "general purpose" language. Maybe Algol, if it's true what they say about similarities to Pascal, particularly the kinds of Pascal that have been adapted to low-level programming by adding pointers and whatnot.

IDK, FreePascal is programmed with FreePascal.

I have learned and forgot the C in past 10 years. 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 Pascal variants that became widely used are not really Pascal. They were extended to the point where they were more C like, and could actually be used to write their own run time library.

The C as it came out to be known, is widely extended and not really represent the hack-job it first were. 

The original C was fully capable of being used to write its own run time library, because is was very level focussed from the start. It was higher level stuff that was added over time. Standard Pascal always lacked low level features. You can't even specify a variable length, or do basic things like 'and' and 'or' them. TurboPascal, and other popular Pascals, added those things. MS Pascal added far less, and never got very far in the market.

[coppice]

IDK, FreePascal is programmed with FreePascal.

USCD Pascal was written in UCSD Pascal.  The only machine dependent code, written in assembler language, was the interpreter.  This wasn't a lot of code and it was pretty easy to port to different machines.  Circa '77...  Considering that the Altair 8800 was introduced in '75 (I bought mine in early '76.  I didn't play with UCSD Pascal until '80 bit it was an important step on the way to modern machines.  The IBM PC was introduced in '81.  It was a slug compared to the 6 MHz Z80 machines running CP/M.

Almost any language can be used to write a compiler to compile itself. That is trivial. However, fully developing a language in that language means writing all the run time support in that language. In most languages this is somewhere between difficult and impossible.

[SiliconWizard]

IDK, FreePascal is programmed with FreePascal.

Yeah. That's the case for many other compilers for other languages actually. But they just had to be bootstrapped at some point. And guess how? Usually using C.

I have learned and forgot the C in past 10 years. 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.

Of course just a matter of personal preference regarding the brackets. I personally find them alright. My keyboard also requires a modifier key for them (AltGr), but that's still a lot less pain than writing "begin" and "end" everywhere. But just preference...

Regarding the case sensitivity, I can understand your feeling annoyed, coming from Pascal, but I do not agree with you. It actually enforces a better and more consistent coding style (how I hate looking at code in which the same identifiers are alternately written in either case, or a mix of both... and I've seen it in Pascal, VHDL code... awful!), and Wirth, the author of Pascal, would agree with me as he later introduced case-sensitivity in the derivative languages he designed, such as Oberon.

[Vtile]

IDK, FreePascal is programmed with FreePascal.

Yeah. That's the case for many other compilers for other languages actually. But they just had to be bootstrapped at some point. And guess how? Usually using C.

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.

[bsfeechannel]

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.

[NorthGuy]

The Pascal variants that became widely used are not really Pascal. They were extended to the point where they were more C like, and could actually be used to write their own run time library.

That's what make them great People who like Pascal syntax can program in Pascal without lacking power of C.

[legacy]

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.