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.
There is no C program that could not be made to run faster using inline assembly given equal knowledge of both languages.

What is sad is that this viewpoint of dislike and ignorance of the power of ASM in a higher level language circles and specifically in production environments.

It's more like the respect and wisdom of a long relationship for me. I've seen bloated and crappy machine level programs written by code jockeys who went to some of the best schools in America who fell in love with the hardware instead of the problem at hand. Sometimes a chainsaw instead of a X-ACTO knife is the right tool to create something when used by someone with real talent.
https://www.youtube.com/watch?v=fyDaxzeFaRk&feature=related
 
3v0, the entire reason we need multi core multi ghz processors is because of bad programmers and bloated HLL language extended process instruction sets varying API and a failure to stop and take a new look at things and redesign them to be more efficient and just throwing additional layers on top.

The reason why we have all these modern processors is that code is decoupled from hardware. Thanks to high level languages, processor designers can design new hardware more freely. Imagine if every piece of software would have to be re-written every time a new processor comes out.
 
Last edited:
...
That is a good example of what I am talking about. I am not familiar with the PIC instruction set, but if I was into PIC coding big time, I would have a library of routines that could do division, multi-word compares, and conversion from binary to ASCII. No doubt C has those routines already. It is not fair to compare the built in routines of a HLL with an Assembler suite where those routines are not readily available. True, it takes time to write those routines once, but they are reusable later.
...

That's a valid point but it still doesn't compare to the speed and ease of C. As a long term ASM coder I have plenty of "library" functions for math and data conversion etc. But C has these already, so in C you can do A = B * C. In assembler it needs to link in the math code, allocate variables for it (is there enough RAM? where to put the variables? Can vars be re-used with other math functions? Can the math code be placed in an optimal position in ROM? Was this code from a different type of PIC with different RAM issues?) etc etc.

All those assembler DECISIONS that can (given enough talent and work) produce much smaller and faster code take considerable time, and risk of something going wrong.

But in C typing the line A = B * C means the compiler already handles what math routines are needed, where they go, what variables can be re-used, what data conversions are needed etc. It may make code a little larger or slower running, but it's practically instant to the coder who can type A= B * C in just 3 seconds and it is DONE. And portable between all applications and microcontroller types.

I think of ASM and C as two different tools, both have strengths and weaknesses and it's been a bit amusing seeing some people here being so very black or white on the issue!

Assembler is a treetrunk and a chisel.
C is pre-cut lumber and a workshop full of carpentry tools!

In both cases you can make a chest of drawers...
And most smart managers in the real world are going to insist on the pre-cut lumber and workshop. But a master capenter knows there will always be times to reach for that chisel, if not for the whole job just for part of the job.
 
Last edited:
That's a valid point but it still doesn't compare to the speed and ease of C. As a long term ASM coder I have plenty of "library" functions for math and data conversion etc. But C has these already, so in C you can do A = B * C. In assembler it needs to link in the math code, allocate variables for it (is there enough RAM? where to put the variables? Can vars be re-used with other math functions? Can the math code be placed in an optimal position in ROM? Was this code from a different type of PIC with different RAM issues?) etc etc.

All those assembler DECISIONS that can (given enough talent and work) produce much smaller and faster code take considerable time, and risk of something going wrong.

But in C typing the line A = B * C means the compiler already handles what math routines are needed, where they go, what variables can be re-used, what data conversions are needed etc. It may make code a little larger or slower running, but it's practically instant to the coder who can type A= B * C in just 3 seconds and it is DONE. And portable between all applications and microcontroller types.

I think of ASM and C as two different tools, both have strengths and weaknesses and it's been a bit amusing seeing some people here being so very black or white on the issue!

Assembler is a treetrunk and a chisel.
C is pre-cut lumber and a workshop full of carpentry tools!

In both cases you can make a chest of drawers...
And most smart managers in the real world are going to insist on the pre-cut lumber and workshop. But a master capenter knows there will always be times to reach for that chisel, if not for the whole job just for part of the job.

Well put and I entirely agree :)
 
Bad programmers and a refusal to redesign alone are a roadmap to trouble. We could be in even deeper trouble if these bad programmers were using ASM because it would allow them to generate bugs at the machine level.

This has absolutely nothing whatsoever to do with C vs ASM though, it is a completely separate subject.

Given the same amount of time and the same talent level any programmer will finish a project sooner with a HLL. It is all about economics, because time is money.

Again this has nothing whatsoever to do with C vs ASM from a technical perspective, I'm referring only to ASM technical merrits not the logistics of managing programmers, that is a completely separate conversation.

Are you really saying that all this could have happened using asm only?
Sure it could have happened but it didn't, and C was a boon to productivity in programming, however the point I'm trying to make here is that it's not C vs ASM as to why modern OS's contain so much code it's the number of layers abstracted from ASM we've come, ASM to C is fine, but there are literally hundreds of other layers now that have caused the code bloat and slow systems speeds and that is slowly being remedied, but only very slowly. The dependencies alone for a quick and dirty pretty looking program nowdays even a simple one is obscene.
 
3v0, you should be asking PG1995 that question not me, whom by the way hasn't made a post in this thread since the 4th page, the topic derailed about then because both you and misterT decided to add additional concepts outside the scope of his original question. I've been attempting to stay on the specific thread topic as PG1995 declared it and based on his queries.

I agree with the core of what you (3v0) say, but have a large number of contentions with the generalities misterT is using, but that is not for further discussion in this thread unless PG1995 is allowed to express him opinion and possibly be given some time to absorb the information that has been presented thus far.

This is a situation where I think it would extremely useful to have a forum feature that would allow a moderator to lock a thread until the original poster's next statement, it would prevent threads like this (and many others) from occurring.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top