For me it's Wile E. Coyote! Always so optimistic with his inventions -- I really appreciate that indomitable spirit of creativity! (despite his utter ineptitude )

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Browsers and OSs are not part of my work. To me, they're just appliances. True, I choose my battles, and I don't even try to understand those. But if it's my project that I'm responsible for and my name goes on it, I won't take that approach.


As I remember, Larry was an excellent pianist and violinist.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

That's especially true with the violin. As many people know, Larry accidentally spilled acid on himself when he was a small child. The doctor recommend taking up violin lessons for physical therapy.

_________________
Cat; the other white meat.

I'm a little late to the discussion but I had a few thoughts:
I had a similar response when someone showed me how they were using C++ constructs to get the compiler to take variable assignments in code and turn them into pin flips on the MSP430 (similar class of microcontroller to what Arduino uses). The code he was getting was extremely small and fast. You can do a lot of really neat stuff with C++ for microcontrollers with no more bloat than you would with C.

I definitely disagree with you on that. Some people point out that C is a good fit for microcontrollers because it is often more efficient on certain systems. Even a $1 MSP430 with 16 registers can be a lot to juggle mentally and use perfectly efficiently. For a large program on a moderately complex microcontroller the compiler will often produce assembly as good or better than what you could do yourself. There are all sorts of weird things the compiler knows to do that you would not think of. One that sticks in my mind on the MSP430 is XORing a register with itself since IIRC it takes less cycles than loading a 0. Compare that to loading a 0 from the 'constant generator' register to subtracting a register from itself to storing the 0 in firmware and loading it in to whatever other weird thing you could do to get 0 and it is easy to see how many cycles the compiler saves in ways you haven't thought of. Another example is the x86 architecture. In the 80s writing your own assembly code could be more efficient than C, but the compiler designers have had 30+ years to perfect what they do and for large projects it would now be very hard for you to out-optimize the compiler by hand.

That is a good point. I have experimented with them a lot and they are useful, but there are things I don't think they can do (or I just haven't figured out how to do it yet.) For example, it would be wasteful to give each function that needs to be fast its own section of zero page. Instead, you could let them reuse the same chunk but you have a problem when one function calls a second function because it will try to use the first functions zero page chunk. I have not figured out how to make the macro tell the function that it is being called from another function, and should therefore use a different part of zero page, OR if it is being called this time as a top level function and should use the first chunk of zero page. If you were willing to have all or part of the function reproduced twice in your binary, you could write a program to automatically make a second copy of any function that is called as a top level AND second level function so each version uses a different part of zero page (assuming of course the binary space/zero page trade off makes sense for you). You could also tell the program how much zero page you are willing to give up for functions so it would not start making copies of functions (which bloats your binary) until it ran out of zero page.

Another helpful thing you could do that C compilers do is look for stretches of functions that are similar or can be rearranged to be similar so that you only need one copy of it, saving space. These functions could be totally unrelated in your mind (bit banging an SD card and driving an LCD) but the compiler will find coincidental similarities and only keep one version of it if it's long enough. For chips with lots of registers this could involve changing which register is used for one of the variables in the SD card routine so that it will look like the LCD routine (not that it matters to the C programmer since registers are invisible to him). Now, imagine writing assembly code that would do the same thing. You would need to create two to three versions of a function and then call the right version in the right place (God help you if you change the function but only remember to update two of the three versions), while also chopping out and saving multiple parts of those three versions that they have in common that don't depend on the different zero pages chunks, while also finding coincidental similarities in the thousands of lines of completely unrelated functions that can be chopped out and saved as well. If you could do that, you might still have to do massive reorganizing for even a minor change in your function since stretches in that function may no longer be similar to stretches in others, although new sections could have new similarities which you now need to find. It would not be possible for an assembly programmer to write a large program that is as small and memory efficient as the compiler's AND still easily readable by humans.

This got me thinking that it might be useful to keep the parts of cc65 that are fast and efficient and do the rest in assembly. I don't think it would be fun to test all of the functionality of cc65 to see what is worth keeping, though. It might be interesting to start a new project and implement only the parts of C that can be converted to assembly very efficiently. I think math calculations would be a good candidate. So would loops like "for" if your compiler were smart enough, for example, to see if the X register held anything useful before the for loop and if X was used afterward for anything to know if X should be saved before the for loop used it. Also, maybe having functions would allow for some optimizations like I mentiond above. Admitedly, this might only appeal to a small group since you would have to know/like both C and assembly.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

True, but LDA zp is 3 cycles, whereas LDA zp,X is 4. The extra cycle you save may not always be worth the space you give up, but with a good compiler you would at least have the option of choosing size or speed.

No, that's not what I mean at all. All my projects have been one-man projects and I have seen big reductions when compiling for size. Whole functions and routines do not need to be near-duplicates for you to benefit. You just need stretches that the compiler can recognize as functionally similar, which is not always obvious to you since it may involve rearranging some things.

That is neat! I should try to make a macro like that. Would you expand it like this:

Most of what I would say has already been said, but I will summarize my views with short versions:
Terrible code can be written in any language. C is not immune.
Microcontrollers can do anything large computers can do. Google Turing machine and Turing complete.
In the last 40 years or so I have heard countless times how "language x will solve all our problems." No language can save us from bad programming.
Modern compilers for modern processors (the PIC is NOT modern, dating from about 1974/75) can do better than the vast majority of us.
Lines of source don't necessarily equate to bytes of code.

But the big question, why did anyone think C on a microcontroller was a good idea?
By 1955 people had already realized that assembly was harder than necessary. A lot of REALLY smart people put in a LOT of effort to make programming more efficient, likely at the expense of runtime efficiency. At a time when a computer with 4K words of memory was fairly large, they put in the effort to create languages like COBOL, FORTRAN, and even ALGOL. If you can find references on the web to Gier Algol, it is rather interesting. The machine the compiler ran on and targeted had 1K words of RAM. The compiler took something like ten passes to compile a program. But it was deemed worthwhile. Keep in mind this was before most of the theoretical science of compilers existed. It was not a trivial exercise.

Jump forward ten years to when the first UNIX version that was written in C (after first being written in assembly) came about. The entire system ran on a machine with 128K bytes or less. The compiler could generate code for smaller machines. By that time, the early 70s, it was already accepted that MOST programs didn't benefit from being written in assembly. That was the preachings of most of the great names in CS: Wirth, Dijkstra, Brinch Hansen, and many others.

Today, we can get a 32 bit processor with 32K of Flash and 4K of RAM, built onto a board with all necessary components, for $4
http://www.mouser.com/ProductDetail/Cypress-Semiconductor/CY8CKIT-049-42XX/?qs=sGAEpiMZZMtIClGg9PMp4%2fOw7X%2fI83v%2fWc%2f7t3%2fqmz2hEinfsBPHYg%3d%3d That is a MUCH more powerful machine than the ones high level languages were first created for. Typically, those will be used in a fixed function device. If you can write the code in C (or some other HLL) and it serves its purpose, why not? The fact is that most people find it easier to write in some HLL than in assembly. The killer app for early micros (with about 4K bytes memory typical) was a high level language (BASIC) to make them easier to program. If you find assembly easier than any HLL, then that's great. But you are most definitely in the minority.

I enjoy writing assembly from time to time, and sometimes it is even necessary. I like to think I'm competent
http://smalltimeelectronics.com/projects/vidovly/avrcog.html. But for day to day development, I am much more productive with C or C++. We are all different, with different tastes and talents. But the vast majority, perhaps 99% or more, will be more productive with a high level language than assembler.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

You could pick between LDA zp and LDA, zp,X with a macro but you could not rearrange firmware like I was describing above to keep zp free and reusable with macros. For large programs a compiler does this kind of thing better than a human can with or without macros.

Right, too complicated for a person but compilers can easily do this kind of thing. Some programs run 2-3 times faster with speed optimizations, and I think a good compiler could manage zp better than a person.

Right, that is a skill we should all try to develop. The problem is that that will never be enough for you to outperform an optimizing compiler on larger programs. On modern processors, it does all of those things better than you can.

Agreed

Compilers definitely surpass humans on modern chips but I don't think we know yet if that is true for compiling larger programs on the 6502, even if its true for short routines. Part of the advantage of HLLs seems to me to be that abstraction sets certain rules which lead to certain assumptions and given those assumptions, we can optimize in ways that would be difficult for an assembler to do. The question is whether the inefficiencies that might be necessary to institute all of C, given the architecture of the 6502, would outweigh the gains you would get from optimization.

People keep making this assertion like it's a religious mantra, but I'm not convinced. There's nothing magic about large programs or optimizing compilers, and the only thing that makes "modern processors" particularly complicated is out-of-order execution (hell, even back in the Pentium days clever programmers were optimizing for multiple-issue.) And sure, a program can probably work out the particulars of instruction ordering with less tedium than a human, but then the next generation of CPUs comes out and it's all different anyways...

Yeah, when it comes to large programs, then human design will win because architectural improvements will matter much more than micro-optimizations. For individual functions with large bodies, or complex loops those are certainly places where hand coding gets outrun by the compilers.

The biggest modern change is writing to the cache hierarchy, which has more to do with architecture than coding, designing your data structures to fit in cache lines and finagling what the overall access patterns will be.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

Compilers are also written by humans. So humans surpass other humans sometimes by knowledge and experience. However, for a human writing a compiler to anticipate all the stupid coding of another human is so much harder.

Or to put it more simple: garbadge in = garbadge out holds true even for the most sophisticated compiler.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

There is something magic about compilers and large program -- cognitive load. Compilers don't suffer from it, but humans do.

Compilers scale across volume. Compilers don't lose track of things. Compilers are much, much better at ferreting out arcane data paths in terms of deciding stuff NOT to compile, and NOT to include.

Consider C++, generic programming, and the standard library. It offers all of these wonderful control structures and other high level things, creates code for them all on the fly during compile, and then proceeds to throw away all the parts that you don't need. You literally pay for only what you use. As a developer you don't have to decide what is safe to toss out. The compiler knows and will do that for you.

Compilers enforce type systems that make large system development safer and more possible. Compilers don't get tired or lazy. When people think they know better, and are able to make short cuts in the code, they're mostly right. When compilers do that, they're always right.

Having the compilers and runtime systems handle much of the lower level minutiae that goes in to system development can lead to safe, more secure software.

Have you seen Jason Turner's neat presentation which illustrates several of your points? The x86 to 6502 translation is very simple-minded, but the C++ to x86 bit is very clever, especially in the optimizing magic surrounding "const".

https://www.youtube.com/watch?v=zBkNBP00wJE&t=4300s

Mike B.