Author Topic: "Stop Teaching C" - Kate Gregory  (Read 43953 times)

0 Members and 1 Guest are viewing this topic.

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8515
  • Country: us
    • SiliconValleyGarage
Re: "Stop Teaching C" - Kate Gregory
« Reply #100 on: November 01, 2016, 05:15:55 pm »
As I mentioned previously C and C++ are very difficult to parse reliably. I think the .h files (or more generally forward declarations) makes the compiler's job a lot easier.
multipass compilation solves parsing problem.

pass 1 : go over source file and collect functions and subroutines. build a map in memory of their definition (what goes in and out) and attach the source or object. once all the files are loaded in ram then all source and object is loaded as well. at this point all routines available are known and also all routines that are being called are known. if a callee is missing : stop compilation as something is missing. if something is not called : remove it as it is unused and not necessary for the program. (this results in automatically stripping superfluous functions from libraries.)

pass 2 : compile all standalone functions ( functions that do not call others ) into machine language. create a callable and in-line variant for each.
pass 3 : compile functions that call others. direct calls become in-line. nested calls become true calls.
repeat pass 3 until top level of hierarchy is reached.
pass 4 : map final memory allocation for all function and assign hard addresses. (essentially linking)
pass5 : spit out binary.

pl/m compilers back in 1972 already could do that. it's 2016. don't you think it is time C started doing that too ?
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Online JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: "Stop Teaching C" - Kate Gregory
« Reply #101 on: November 01, 2016, 05:33:09 pm »
same goes for the stupidity with typecasting. on some compilers an in is 8 bit , on other it is 16 bit , ... why on earth does that have to change ? remember the ariane rocket that blew up ? that was because the real hardware had an int as 16 bit while on the emulator it was treated as 32 bit.... the same code overflowed in the rocket ... because the idiots who build compilers think it is ok to have different definitions for the same type....
while i agree, fixed lenght types do exist (int8_t, uint32_t etc.)
 

Offline Kalvin

  • Super Contributor
  • ***
  • Posts: 2145
  • Country: fi
  • Embedded SW/HW.
Re: "Stop Teaching C" - Kate Gregory
« Reply #102 on: November 01, 2016, 05:39:17 pm »
In addition to providing the interface, the .h files make it possible to provide the libraries of the functions without providing the actual source code.
and why is that needed ?

if the compiler traverses all files in a directory ti will find the libraries. whether those exist as .c files or as .obj . doesn't matter.

my claim is : there is no need for includes and .h files. all the compiler has to do is look in the directory where the project is stored (and its subdirectories) and see if it can find the function, either in source or object. if it can't find it there : stop compilation.

How about the constants, type definitions, data structures etc. There is a lot more than just functions in programming.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: "Stop Teaching C" - Kate Gregory
« Reply #103 on: November 01, 2016, 05:51:52 pm »
As I mentioned previously C and C++ are very difficult to parse reliably. I think the .h files (or more generally forward declarations) makes the compiler's job a lot easier.
multipass compilation solves parsing problem.

pass 1 : go over source file and collect functions and subroutines. build a map in memory of their definition (what goes in and out) and attach the source or object. once all the files are loaded in ram then all source and object is loaded as well. at this point all routines available are known and also all routines that are being called are known. if a callee is missing : stop compilation as something is missing. if something is not called : remove it as it is unused and not necessary for the program. (this results in automatically stripping superfluous functions from libraries.)

pl/m compilers back in 1972 already could do that. it's 2016. don't you think it is time C started doing that too ?
GCC can do that just fine for many years BUT you have to be carefull with interrupt routines which aren't called from anywhere else.
Besides that there is much more to compiling C than you seem to be aware of. The first step is collecting all the header files and evaluating the pre-processor macros by the pre-processor and put everything in one file with pure C code which is then compiled by the compiler into an object file. Compiling a C program consists of: pre-processing, compiling and linking. The pre-processing stages makes it easy to re-use code by using constants defined in one place and/or include/exclude parts of code depending on variables (which can be supplied on the command line).
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #104 on: November 01, 2016, 06:08:51 pm »
you have to be carefull with interrupt routines
which aren't called from anywhere else

in the theory the body of an isr should be at least loaded
therefore their names should compare inside an initializer

e.g.
Code: [Select]
void isr_init()
{
  ..
  isr_set(isr_machine_exception, 0x00000100);
  ..
}

it's not the only way to handle isr, I find it useful
 

Offline John Coloccia

  • Super Contributor
  • ***
  • Posts: 1208
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #105 on: November 01, 2016, 07:01:20 pm »
As I mentioned previously C and C++ are very difficult to parse reliably. I think the .h files (or more generally forward declarations) makes the compiler's job a lot easier.
multipass compilation solves parsing problem.

pass 1 : go over source file and collect functions and subroutines. build a map in memory of their definition (what goes in and out) and attach the source or object. once all the files are loaded in ram then all source and object is loaded as well. at this point all routines available are known and also all routines that are being called are known. if a callee is missing : stop compilation as something is missing. if something is not called : remove it as it is unused and not necessary for the program. (this results in automatically stripping superfluous functions from libraries.)

pass 2 : compile all standalone functions ( functions that do not call others ) into machine language. create a callable and in-line variant for each.
pass 3 : compile functions that call others. direct calls become in-line. nested calls become true calls.
repeat pass 3 until top level of hierarchy is reached.
pass 4 : map final memory allocation for all function and assign hard addresses. (essentially linking)
pass5 : spit out binary.

pl/m compilers back in 1972 already could do that. it's 2016. don't you think it is time C started doing that too ?

I'm not sure you're thinking this through clearly. Consider something like this:

a * b;

To do what you suggest would require looking through every tiny little bit of code to see just what the heck "a" is. Do you intend to multiply a*b, or are you declaring a pointer to something of type a? That's just one example.

I could keep going on this, but there's a reason C is the way it is, and why it hasn't really changed. More modern languages don't have ambiguities like this, or at least they're limited and easily addressed, so the compiler doesn't run into a brick wall. C is just not well suited for this sort of thing.
 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: "Stop Teaching C" - Kate Gregory
« Reply #106 on: November 01, 2016, 10:18:21 pm »
my claim is : there is no need for includes and .h files.
Correct. Just put everything in a single source file - makes the compiler's job a lot easier!  ;)
 

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 11534
  • Country: my
  • reassessing directives...
Re: "Stop Teaching C" - Kate Gregory
« Reply #107 on: November 01, 2016, 10:50:25 pm »
same goes for the stupidity with typecasting. on some compilers an in is 8 bit , on other it is 16 bit , ... why on earth does that have to change ? remember the ariane rocket that blew up ? that was because the real hardware had an int as 16 bit while on the emulator it was treated as 32 bit.... the same code overflowed in the rocket ... because the idiots who build compilers think it is ok to have different definitions for the same type....
while i agree, fixed lenght types do exist (int8_t, uint32_t etc.)
the rocket programmer was not aware of that, so the compiler programmer is to be blamed.
Nature: Evolution and the Illusion of Randomness (Stephen L. Talbott): Its now indisputable that... organisms “expertise” contextualizes its genome, and its nonsense to say that these powers are under the control of the genome being contextualized - Barbara McClintock
 

Offline John Coloccia

  • Super Contributor
  • ***
  • Posts: 1208
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #108 on: November 01, 2016, 11:22:59 pm »
Believe it or not, it's for machine independence. Blame the idiot programming team that depends on running the code in simulation to check for overflows and things like that. It's a failure in specification and could happen regardless of language.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: "Stop Teaching C" - Kate Gregory
« Reply #109 on: November 01, 2016, 11:34:19 pm »
same goes for the stupidity with typecasting. on some compilers an in is 8 bit , on other it is 16 bit , ... why on earth does that have to change ? remember the ariane rocket that blew up ? that was because the real hardware had an int as 16 bit while on the emulator it was treated as 32 bit.... the same code overflowed in the rocket ... because the idiots who build compilers think it is ok to have different definitions for the same type....
while i agree, fixed lenght types do exist (int8_t, uint32_t etc.)
IMHO you should always use the fixed length types (inttypes.h) and not the typical C types (char, int, long, etc) because they are defined poorly. Also check the range of floating point types to make sure you don't run into trouble. See http://stackoverflow.com/questions/752309/ensuring-c-doubles-are-64-bits
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #110 on: November 02, 2016, 02:06:55 am »
Quote
remember the ariane rocket that blew up ? that was because the real hardware had an int as 16 bit while on the emulator it was treated as 32 bitthat was Ada.   "AdaTran", actually - badly converted Fortran.
https://vimeo.com/44792649#t=530s
Language used sounds like it was one of the least of their problems :-(
(Though I like the comment "If it had been written in C, it wouldn't have blown up.")
« Last Edit: November 02, 2016, 02:26:54 am by westfw »
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #111 on: November 02, 2016, 07:49:51 am »
my claim is : there is no need for includes and .h files.
Correct. Just put everything in a single source file
- makes the compiler's job a lot easier!  ;)

sarcasm?  :-DD
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #112 on: November 02, 2016, 07:58:56 am »
they are defined poorly

yep, a mess

e.g.
m68k (CISC)
a long is 32bit
a short is 16bit
a char is 8bit(2)
a word is 16bit
there is no half
a long long is 64bit

MIPS (RISC)
a long is 32bit
a short is 16bit(1)
a char is 8bit(2)
a word is 32bit <------
there is also half (word), which is 16bit
a long long is 64bit <-----


(1) but sometimes with PowerPC (RISC) is 32bit
I have seen sizeof(short)=2byte, sometimes =4byte
WTF  :wtf: :wtf: :wtf:


(2) some DSP by TI says that char is 16bit  :-// :-// :-//
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #113 on: November 02, 2016, 08:07:57 am »
word and half are not *C terms*
they come from CPU manuals
like a contribute to the confusion  :palm:

I believe "word" was 16bit with 68K
(which is a true 32bit machine)
because the 68000 bus was 16bit
while the R2000 bus was 32bit

therefore half (word) makes sense for MIPS

the problem is: the C language should not stay
so close to the hardware, especially if it aims
for being a portable language

it's just an example, it shows the wrong attitude
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: "Stop Teaching C" - Kate Gregory
« Reply #114 on: November 02, 2016, 08:20:00 am »
word and half are not *C terms*
they come from CPU manuals
like a contribute to the confusion  :palm:

I believe "word" was 16bit with 68K
(which is a true 32bit machine)
because the 68000 bus was 16bit
while the R2000 bus was 32bit

therefore half (word) makes sense for MIPS

the problem is: the C language should not stay
so close to the hardware, especially if it aims
for being a portable language

it's just an example, it shows the wrong attitude

It shows that the language doesn't fit your problem you are using it for.

It doesn't really show that the language has the wrong attitude...

Take for example early PC development, with 'near pointers' and 'far pointers' and 'huge pointers'. Much to C's credit it could actually be made to work with such painful system with only a few extra key words.

The problem isn't that the language wasn't portable, it is that the programmer was unaware of the assumptions they are working under.

 I am currently working on something to process audio files. It would be really easy for me to write a program that reads a WAV file on my PC, but fails on other h/w due to endian mismatch.

Do I say "Stupid language", or "Stupid hardware designer", or "Stupid me"?

I say "stupid me" - I should be doing it in something like MatLab anyway, but hey, I know C, I am lazy, and the problem looks like a nail to me. :)
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #115 on: November 02, 2016, 08:21:28 am »
Quote
m68k (CISC)
a long is 32bit
a short is 16bit
  :

x86 (CISC):
depends on compiler settings.  (actually, I'm pretty sure that's true of MIPS64 as well.  Probably ARM64 too; it's at least a gcc thing.)
I think you get your choice of "longs and ptrs are 32 bits", "longs are still 32bits bit pointers are 64", "longs are 64bits but pointers are still 32bits", and "longs and ptrs are both 64bits."
It's a bit shocking how much code breaks when sizeof (long*) != sizeof(long)...
« Last Edit: November 02, 2016, 08:23:22 am by westfw »
 

Offline John Coloccia

  • Super Contributor
  • ***
  • Posts: 1208
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #116 on: November 02, 2016, 08:28:02 am »
they are defined poorly

yep, a mess

e.g.
m68k (CISC)
a long is 32bit
a short is 16bit
a char is 8bit(2)
a word is 16bit
there is no half
a long long is 64bit

MIPS (RISC)
a long is 32bit
a short is 16bit(1)
a char is 8bit(2)
a word is 32bit <------
there is also half (word), which is 16bit
a long long is 64bit <-----


(1) but sometimes with PowerPC (RISC) is 32bit
I have seen sizeof(short)=2byte, sometimes =4byte
WTF  :wtf: :wtf: :wtf:


(2) some DSP by TI says that char is 16bit  :-// :-// :-//

The basic way it works is:

- int is USUALLY the word size of the machine, thought that's generally no longer true on 64 bit systems
- char is the smallest addressable unit, which is normally 8 bits, but there are a number of processors (usually DSPs) where it's larger. It's always 8 bits or more regardless, though

Beyond that, the types are defined like this:

- each type must hold some MINIMUM value. For example, a char must be able to hold at least +/-127
- each type must not be smaller than the one that came before. So for example, just looking at the minimums, it's conceivable that a short be 64 bits and an int 32 bits, but that's not allowed.

So anyhow, if it's not enough to know the minimums, then you need to use fixed width types. I agree...it's a mess.
 

Offline Kalvin

  • Super Contributor
  • ***
  • Posts: 2145
  • Country: fi
  • Embedded SW/HW.
Re: "Stop Teaching C" - Kate Gregory
« Reply #117 on: November 02, 2016, 08:33:15 am »
In C  the sizeof(char) == 1, but the char may be 8, 16, 24 bits or something else depending of the architecture. For example, in some DSPs a char is 16 bits or even 24 bits.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: "Stop Teaching C" - Kate Gregory
« Reply #118 on: November 02, 2016, 08:40:51 am »
It shows that the language doesn't fit your problem you are using it for.

That's a valid observation, but it raises two important questions:
  • why do people (plural) use the "wrong" language for the problem
  • what is the domain for which there are no better languages
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #119 on: November 02, 2016, 10:03:53 am »
I'm pretty sure that's true of MIPS64 as well

yes, I confirm it, it's a big mess with MIPS64

I have recently bought a few cpu modules for my Malta board

although "CoreLV-5KC" sounds like the cpu used by SGI in their Indy-station
"5K" doesn't mean "R5000"

"4KC" means MIPS32r2, "5KC" means MIPS64
the first one is a true 32bit machine, the second one is a true 64bit machine
but it also comes with 32bit legacy mode

confused? well … looking at the cpu user manual you will have a shock
especially if you compare what you read with the Core20K's UM

Core20K is "5kc", but … it has different definitions in its AN

so, what the frog is 64bit? it's not clear when they talk about
pointer, and data, sometime p_uint64_t is NOT a 64bit pointer
(especially in legacy 32bit mode) so, why they call it _64_t ?
not clear at all  :palm: :palm: :palm:

It's a bit shocking how much code breaks when sizeof (long*) != sizeof(long)...

yes, an example is the Atlas board  :palm: :palm: :palm:
it accepts both the cpu modules, 32bit and 64bit
but you can't recompile the same examples without having to deal a lot of messes

actually you have two branches, the same code forked into two branches
because of messes with sizeof (long*) != sizeof(long)
 
long* is 64 bit with "5kc" (but it can also be 32bit if you use the legacy mode)
long* is 32bit with "4kc"

computer science, feelings of pity and sorrow for someone else's misfortune  :D
 

Offline setq

  • Frequent Contributor
  • **
  • Posts: 443
  • Country: gb
Re: "Stop Teaching C" - Kate Gregory
« Reply #120 on: November 02, 2016, 10:06:39 am »
computer science, feelings of pity and sorrow for someone else's misfortune  :D

This is why my bench is analogue only. It's an escape from the insanity.
 

Offline obiwanjacobi

  • Frequent Contributor
  • **
  • Posts: 988
  • Country: nl
  • What's this yippee-yayoh pin you talk about!?
    • Marctronix Blog
Re: "Stop Teaching C" - Kate Gregory
« Reply #121 on: November 02, 2016, 10:12:50 am »
Although the D language looks excellent, it also states it was designed for 32 bit and up.
I can find compilers for the Windows and Linux and some ARM (not an expert).

So for smaller MCU there is no support it seems.

My 2c.
Please continue with the C/C++ bashing..

:horse:   

:popcorn:
Arduino Template Library | Zalt Z80 Computer
Wrong code should not compile!
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #122 on: November 02, 2016, 10:14:10 am »
That's a valid observation, but it raises two important questions:
  • why do people (plural) use the "wrong" language for the problem
  • what is the domain for which there are no better languages

good question, I have no answer

concerning being the wrong language, or the right language
that is the reason why I am developing my own language

mainly because I am tired to have to deal with gcc
but I am also tired to have to deal with C itself
but it's pure hobby for my own research (=pleasure)

I mean, I am obliged to use C/C++ for my job  :-//
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: "Stop Teaching C" - Kate Gregory
« Reply #123 on: November 02, 2016, 10:19:40 am »
that is the reason why I am developing my own language

but it's pure hobby for my own research (=pleasure)

The language is, of course, the easy bit. Thereafter comes the tools, libraries, documentation, staff training... The tools and staff training are very siginificant issues with domain specific languages (DSLs).

But "because I want to have fun doing it" is a perfect, sufficient reason :)
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: "Stop Teaching C" - Kate Gregory
« Reply #124 on: November 02, 2016, 10:22:12 am »
  • why do people (plural) use the "wrong" language for the problem
  • what is the domain for which there are no better languages

In my case, it is because I am now old and feel that most languages are fads, and the language isn't really what is of interest to me. I'm doing things for fun, and there is nothing I can't explore in C...

I am currently mostly using the TCC compiler (http://bellard.org/tcc/ ) - the entire compiler is well under 300kB. I have it on a USB stick which I can plug into any PC I have handy and scratch out some ideas, compile in seconds and do stuff with zero fuss, rather than multi-MB downloads.

When I need to I can also compile and use exactly the same code on Intel, Sparc, PowerPC and various ARM systems (using GCC) and get the benefits of a pretty good optimizing compiler.
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf