C Programming: pointers

[nsaspook]

These things are all doable in asm. If you think about it doesn't a structured language compiler produce structured ASM code or machine if it does not do the translation to ASM.

I would say no to that. Some of the best HLL systems produce some of the most human unreadable and unstructured code possible when full optimization is enabled. All of the horrible tricks we don't want humans to use for optimization are used by the (gcc) RTL code generator backend because it's mainly solving an equivalence problem not a direct programming problem.

 

[3v0]

I would say no to that. Some of the best HLL systems produce some of the most human unreadable and unstructured code possible when full optimization is enabled. All of the horrible tricks we don't want humans to use for optimization are used by the (gcc) RTL code generator backend because it's mainly solving an equivalence problem not a direct programming problem.

I was thinking of the straight translation with all optimizations off.

 

[nsaspook]

I was thinking of the straight translation with all optimizations off.

But who actually uses that mode on finished code if they have a choice? I and most others use it (optimizations off) to speed up the incremental coding and debug stages where straight translation of machine code output is usually faster compiling and easier for a debugger to track source symbols to viewed machine code. Highly structured code is usually not the most efficient (fastest and/or smallest) way to translate a programming function to run-able code on a computer. I understand why many people love ASM programming, the symbolic structure that can enhance human creativity and problem solving in a HLL like C can be stripped down to a precise placement of operations instead. That works great and is efficient as long as there is a rough equivalence of the current problem to machine code but as problems become more abstract the ability to find an direct equivalence at the machine level requires a translation step by a human or computer. The level of efficiency of the sometimes incomprehensible computer translation is what makes C popular in embedded programming.

 

[Ian Rogers]

Do you not find that writing a decent sized program, even for testing purposes, is tons quicker in C... I can write a program incredibly quickly in C... I know the same can be done in assembly, but the speed of writing plus the speed of debugging is oodles better than pure assembly... This for hours worked is far more efficient..

The other thing is... If I have written a peice of code to make a pic16f887 read a pin and display the results on a LCD screen.... If I discover part way through that the pic16 is too small and I need a pic18 or pic24... All my coding isn't in vain... As Mr T keeps harping on about.. The code is portable... Pic 16 - 18 - 24 - 32 assembler are too different to port code from one to the other....You can!! but its harde than with C...

 

[nsaspook]

Do you not find that writing a decent sized program, even for testing purposes, is tons quicker in C... I can write a program incredibly quickly in C... I know the same can be done in assembly, but the speed of writing plus the speed of debugging is oodles better than pure assembly... This for hours worked is far more efficient..

An assembly expert could be just as fast but the assembly code needed for easy debugging at that level is usually not the assembly code needed for max efficiency so usually the expert starts writing the more efficient machine version first then adds debugging if needed that might change the efficient machine version structure of the program to fine tune the code, then the result is put back into a more efficient machine version again. With C the difference between the source version that generates the most abstract efficient machine version and the easily debugged source code version can usually be much closer with a good compiler.

 

[NorthGuy]

Do you not find that writing a decent sized program, even for testing purposes, is tons quicker in C... I can write a program incredibly quickly in C... I know the same can be done in assembly, but the speed of writing plus the speed of debugging is oodles better than pure assembly... This for hours worked is far more efficient..

I am a slow thinker. It takes me days to figure out how the program should work. And then it takes relatively short time to code. Probably would be faster to code in C ...

The other thing is... If I have written a peice of code to make a pic16f887 read a pin and display the results on a LCD screen.... If I discover part way through that the pic16 is too small and I need a pic18 or pic24... All my coding isn't in vain... As Mr T keeps harping on about.. The code is portable... Pic 16 - 18 - 24 - 32 assembler are too different to port code from one to the other....You can!! but its harde than with C...

I completely agree. That's what started the debate. If you go with Assembler, your code is not portable, sort of one-time shot. But then look at Linux software. It is portable. I guess, you still can compile and use some of the packages that were written 20 years ago (perhaps with little modifications). But look, most packages were re-written or replaced with new ones. Perhaps if you don't have anything portable, it'll force to write newer, better programs 10 years from now rather than adopting your old programs to the ever changing world?

Were are programs that I wrote 30 years ago? They're in the dust. But back then I wanted my programs to be portable and reuseable. I had little packs of punch cards which were supposed to help me write better programs using my favorite PL/1 throughout my entire life. They were very well organized and I kept them in the shoe boxes with nice labels, so that I could find them easily. Where are they now? In the dust. I don't think I could write something using PL/1 now. My preparedness for the future only helped me to stay longer in the past because I din't want to take parts with my favorite PL/1 for way longer than I should've had. Very few people know what is PL/1 and how to use punch cards. 30 years from now, who will ever rememver that there used to be primitive embedded devices called MCUs?

 

[nsaspook]

Were are programs that I wrote 30 years ago? They're in the dust. But back then I wanted my programs to be portable and reuseable. I had little packs of punch cards which were supposed to help me write better programs using my favorite PL/1 throughout my entire life. They were very well organized and I kept them in the shoe boxes with nice labels, so that I could find them easily. Where are they now? In the dust. I don't think I could write something using PL/1 now. My preparedness for the future only helped me to stay longer in the past because I din't want to take parts with my favorite PL/1 for way longer than I should've had. Very few people know what is PL/1 and how to use punch cards. 30 years from now, who will ever rememver that there used to be primitive embedded devices called MCUs?

For me knowing all the gritty individual details of every language is not what's important. I once was very good at Modula-2, forth and several other 'dead' languages. The details of those languages are mainly gone from my head but the patterns and structures used in those languages are still there.

Was never a PL/1 programmer but I was pretty good at punching up a FORTRAN deck for a batch job on several of the old AUTODIN network systems I once worked on.
http://www.jproc.ca/crypto/autodin.html

 

[NorthGuy]

For me knowing all the gritty individual details of every language is not what's important. I once was very good at Modula-2, forth and several other 'dead' languages. The details of those languages are mainly gone from my head but the patterns and structures used in those languages are still there.

Exactly. I agree 100%. There's no reason to get "married" to a particular language. You can learn programming with any language and then use your skills to write in any language that you (or your boss ) find suitable at a time and place.

 

[3v0]

But who actually uses that mode on finished code if they have a choice?

We were talking about the possibility of creating structured code in asm. I simply pointed out that it is possible because compilers do so, with the condition that we turn off all optimization. It only proves the point that the compiler can generate structured asm which should not be a supprise to anyone. If the compiler can, then it is possible for humans to do so too. Heck just look at the asm output for debugging in mplab (or your favorite source level debugger) and one can see it in action.

A good optimizer can tighten up the code more then the asm programmer because the optimized code does not have to be transparent to humans. To a degree the tightness of asm is myth and has been for decades. And yes there are bad compilers that generate way too much code. There are also lousy asm programmers. The free versions of the microchip compilers are anything but tight. But it is a heck of a lot cheaper to spend 50 cents or a buck extra to get more memory then to buy a two or five grand compiler.

 

[atferrari]

My preparedness for the future only helped me to stay longer in the past because

Wow! Never seen this put in writing. You got me thinking...

 

[killivolt]

Wow! Never seen this put in writing. You got me thinking...

I believe this is an interesting thought. I've thought about it, but never could put it to words.

Edit: I keep telling people I'm analog not digital. I was ok, with 1v peak to peak. But, now it's packets?

Edit: Edit: I didn't have time to write what I mean, after re-reading. I mean with Audio and Video, Analog Video vs Digital, I have to change my way of thinking.

My preparedness for the future only helped me to stay longer in the past.

NorthGuy, this looks like a good signature