Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

hardware is still coded with machine/assembly language for efficiency, speed, etc.

Status
Not open for further replies.
OK my turn. C is easily converted into assembly language. Not one to one, but easily. That's really the whole point of the language. Pointers are in fact indirect addressing. Strings are null terminated which is something you might do in assembler. I think there were some instructions like increment and test. The entire set of variable constructs are very close to how you might access them directly in assembler.

Before C it might have been difficult to find byte arrays and pointers. The "cool stuff" comes from the libraries because they are written in C and C generally produces tight code. The compiler is generally written in C, so it's easy to "cross compile" programs.

Try that with BASIC, ALGOL, FORTRAN, APL, LISP, SNOBOL, COBOL, PL/1 all of which I had some experience.

I'm not sure about JAVA, Modula/2, FORTH and PASCAL. PASCAL, I have worked with. The others, no.

What really slows C down is not operating natively. What I mean is if the target has byte instructions and byte addressing and the compiler uses them, great, but if the machine only offers say 32 bit word addressing, then there will be more overhead.
 
Last edited:
Eric,

If I am understanding correctly what you saying regarding 'complexity' , its a fact that 'C' libs are written using assembler.

So surely someone must be able to write these 'complex' libs using assembler.

Certainly complex programs can be written with Assembler. However, it takes many instructions and lines of code to do so. Some HL constructions that only take a line or two in HL generate code that would take many instructons in Assembler. So I consider a language HL if it expands a code sequence into many instructions. Some assemblers have a facility call procs or macros that can output a sequence of instructions based on input parameters. But they are more or less 'brain dead" in that they only work with the input parameters, and don't know anything about the overall program like a HL does.

Ratch
 
OK my turn.
Before C it might have been difficult to find byte arrays and pointers. The "cool stuff" comes from the libraries because they are written in C and C generally produces tight code. The compiler is generally written in C, so it's easy to "cross compile" programs.
.

hi kiss,
This is the point in my post. 'C' libraries are written using assembler, not 'C'.

In my experience programs written in C do not create 'tight' code when compared to assembler, quite the opposite, also a compiled C runs slower than a well written assembly program.

I am not anti 'C' in anyway, it suits many programmers and gives satisfactory results, but at a cost of program size and speed.

E.
 
KISS,

OK my turn. C is easily converted into assembly language.

We are now discussing what defines a HL, not how easily it can be converted into Assembler. However, I will agree that if you can understand what the program is doing, you can code into Assembler regardless of its original HL.

Ratch
 
From your perspective yes.

One problem with this thread is that people posting to it have different perspectives.

I doubt saying anything here will change anyone's mind.

Nobody will change their mind overnight but most will find there is power on the "Dark Side". Yes, it can be perverted into a glowing mass of bloat but the force is not evil and is only corrupting when used without proper training.
View attachment 63111
 
Last edited:
Eric,



Certainly complex programs can be written with Assembler. However, it takes many instructions and lines of code to do so. Some HL constructions that only take a line or two in HL generate code that would take many instructons in Assembler. So I consider a language HL if it expands a code sequence into many instructions. Some assemblers have a facility call procs or macros that can output a sequence of instructions based on input parameters. But they are more or less 'brain dead" in that they only work with the input parameters, and don't know anything about the overall program like a HL does.

Ratch

hi,
For once, I almost agree with you..;)
Except for the text section highlighted in bold text, in that the section doesn't make any sense.

You cannot endow a compiler directive with self awareness.:confused:
E.
 
Last edited:
hi,
For once, I almost agree with you..;)
Except for the text section highlighted in bold text, in that the section doesn't make any sense.

You cannot endow a compiler directive with self awareness.:confused:
E.

But you can, it's called an optimizer. The good ones use rules from the best ASM programmers in a expert system to look at program structure and rewrite the final machine code.

https://dl.acm.org/citation.cfm?id=51617
https://www.electro-tech-online.com/custompdfs/2012/04/mres.pdf
 
Last edited:
Eric,

You cannot endow a compiler directive with self awareness.

I never said that a HL compiler that is aware of its program is sentient or possesses consciousness. But it can be aware of its program housekeeping duties, like what libraries it needs, what extra memory is necessary, whether to release the memory used by the variables or arrays, code optimization, stack management. Stack management is a good one. If an Assembler wants to use some local variables in a subroutine, he has to move the stack pointer and zero out the extra stack memory if necessary. Then he has to keep track of where on the stack his input variables to the subroutine now are. That is all done by the "awareness" feature of the compiler, and the programmer doesn't need to worry about that in HL.

Ratch
 
Eric:

From Wikipedia: https://en.wikipedia.org/wiki/C_(programming_language)#Libraries

"...Libraries are often written in C because C compilers generate efficient object code;..."

"efficient code" only in comparison to other HLL's, not to well written assembler.

C has it's uses, presumably most of the Windows OS is written in C, and obviously most of Linux/Unix.

If you've got enough power to throw at a problem it doesn't matter greatly - but going back to the previously mentioned AmigaOS, the assembler replacements for the C written OS were a small fraction of the size, and ran a LOT faster than their C versions. But that was on a machine running at 7MHz odd and only 512K RAM - you didn't have a lot to play with, yet it still multitasked better than a multi-GHz PC.
 
KISS,

I will match my skill as a Assembler programer to what C does any day.

Ratch
 
Last edited:
nsaspook,

Sounds like an old Hong Kong martial arts movie.
Together we can defeat any foe.

Not "we", just I. Call it a mental action scene with a "C" rating. For computer language inappropriate for top performance.

Ratch
 
The beauty of a HLL with a good optimizer is that the programmer can write an easy to read and debug program and let the optimizer make it efficient. As I have pointed out in the past the code generated by a HLL does not have to be readable. As long as it works it is good. Thus a compiler is free to use methods that an ASM programmer should not be using.
 
Yep, the Amiga was pretty decent. I did buy the A1000 after all. They did, in fact use a small floppy drive, but they used composite video as output. Memory and expansion was totally nuts, but they at least tried. Animation was MUCH better than the PC could do at the time because they moved that stud to custom chip with something like 8 depths.

The early days of the 80xx series of assemblers just gave me headaches when things like LDA, A, B would mean something like put B into A. I forget the instructions and the syntax and I was very much put off by it. I came from the MOV A, B which means move A to B. I just hated that logic. It may have been about the time of CP/M
 
nsaspook,
Not "we", just I. Call it a mental action scene with a "C" rating. For computer language inappropriate for top performance.
Ratch

The all powerful tiger, strength, quickness and agility. ;)

Aside from the "my foo is better than your foo" stuff, I find a lot of hardware tech types just don't like to type, have never taken a format touch-typing class and look at a wordy HLL as a huge bother. I was force-fed typing on a old UGC-6 teletype with nothing on the keys, was required to be able to type blindfolded (I'm not making this up) and had to type random 5 letter code groups at 75wpm perfectly for 5 min to pass the course.

I'm curious, how many here are touch-typist? Maybe it's not so uncommon today with everyone owning a computer at birth.
 
Last edited:
Definitely not a touch typist, but did take a typing course. When programming all of the *^#%$12 and whatever type keys just are not in the range of the touch typist. The dumb part, of course, is the QWERTY keyboard design is designed to slow you down.

The ASR33 keys you had to press too hard and the keypunch keyboards were worse yet.

What's a typewriter? Oh it's like a keyboard and a printer directly attached and you were only able to correct the last letter.
What's a dictionary? It's like Google, only in book form.
 
I think one thing that is really overlooked here between a high level language and assembler is "overhead" in the final program.
With a level language, you are calling libraries into your program that has almost everything incuded for a specific task.
With assembler you are using only the recources which you require for the task.

Another point is, that with a high level language you don't know the architeture of the hardware used for the cpu,mcu.
With assembly language, you have to know the architecture of the cpu,mcu.

You can be the best high level programmer in the world but still not know the cpu or mcu.

That is where a high level language would be an asset to say a company that uses different cpu's and or mcu's.
 
I've got one leg on either side of the fence. These days I program PIC code in C but I always check the compiler's ASM output, and usually turn optimisation off.

I program in what i like to call "C--" in that it is very vertical using only the simplest C commands and easily lends itself to changing areas of code to ASM, and I put chunks of inline ASM in wherever it is needed to increase performance.

So I've got the best of both worlds; speed and compactness of ASM where needed and the ease of using large arrays and 32bit/float math where needed. My foo is half Yin and half Yang... Just the way Buddha intended... ;)
 
Status
Not open for further replies.

Latest threads

Back
Top