I think it's telling that you use one of the most successful businesses in the world as an example of a company that produces new technology that isn't good technology. At least by the yardstick most of the rest of the world uses (e.g. stock valuation, market capitalization), they produce a great deal of good technology.

Edit: Fixed attribution

_________________
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?

I've been sitting here really enjoying this conversation, so thanks for that. It's been a fun read. But if in any part of that last statement you're referring to the x86 platform, then I'll just come right out and say it: that's not even close to reality. Any half-decent asm programmer can write code that runs at least 2x-5x faster (and greater) than compiled C code -- I know I can. Even heavily "optimized" C is still not the same as pure assembly, nor is embedded assembly within C. The language design itself is the primary reason. We can write code that screams along at full speed, one instruction after another, two at a time on newer CPUs, deciding whether or not we even need a pointer or the stack, which instruction or addressing mode meets our need, and as an added bonus -- guaranteeing not to stall a pipeline or miss a cache due to working directly with the silicon and knowing exactly where we are in memory at all times. C just doesn't, again, because of the way it is designed. I like to think of x86 assembly as 6502 assembly on a ridiculously grand scale, and I sure haven't heard anyone suggest we should write 6502 programs in C.

Of course you can put out a product much faster (and even that is changing now, too -- we have come a long way within our small community), but pure assembly will always run significantly faster in an incredibly small code space. It's that simple. All those things you mentioned (register allocation, pipeline stalls, etc.) are part and parcel of what makes us tick, and yes we can and do keep track of it all (we have cycle contests even at 3 ghz), so while literally every other point you have made thus far has been arguably more or less dead-on, the last one is false and has been proven over and over.

If by the x86 platform you are referring to current generation (e.g. x64 architecture) platforms, then seems that Intel pretty much agrees with me on this point:

"Assembly is often used for performance-critical parts of a program, although it is difficult to outperform a good C++ compiler for most programmers."

https://software.intel.com/en-us/articles/introduction-to-x64-assembly/

BTW, neither I nor I suspect Intel would claim that given unlimited time, a human could not outperform a good C compiler (which itself is more efficient than a C++ compiler). But given a reasonable amount of time (where reasonable might be defined as three to five times as much time as it would take a C programmer of equivalent skill to write equivalent code), the C compiler will generate code of equal or faster speed. Some architectures skew this even more in favor of the compiler (e.g. those with large numbers of registers and/or register windows) and some skew it more in favor of assembly (6502 is an extreme example where even a novice assembly programmer can beat a good C compiler).

Compiler design is a fascinating subject. Just as microprocessors have evolved tremendously in the last few decades, so has the subject of compiler design. Modern architectures (x64, ARM) are designed hand-in-hand with compiler writers in order to produce an optimal blend of technology to maximize the efficiency of compiled languages, NOT for hand-coded assembly language.

By the way, much of human progress is driven by increasing levels of abstraction. Human working memory can only handle a limited number of ideas at once. This is the whole point behind the evolution in high level languages and why it is a good thing for most programmers to eschew assembly in favor of higher level languages at least on modern CPUs.

_________________
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 not how I read it, but I'm not on the outside looking in, nor am I trying to convince you to use my compiler. I think they pretty much agree with me.

Anyway, I'm not up for the religious war.

I agree with you. And that's one reason why electronics is my hobby, not my profession.


Your experience is perfectly valid. But the bottom line is that businesses operate vastly more efficiently than they have in the past because of the deeply flawed efforts of the company you disdain. And while the market has served up plenty of other deeply flawed alternatives, none of them provided enough of an advantage over Microsoft's offerings to significantly alter the market -- at least not until Google and Apple came along. There is no PerfectOS, no matter how much the Apple and Linux fanboys claim otherwise.


There is a lot of FUD out there about snooping. Bottom line is that Apple, Google, Microsoft, and others all do it for advertising purposes. You can opt out and give up smartphones, web browsing, smart TVs and many of the other advantages modern technology brings. But you may not have to give up as much privacy as you think in order to enjoy most of the value that technology brings. Have a look at Bruce Schneier's web site (https://www.schneier.com/) for some ideas. It keeps me in touch with the most significant threats to my privacy and lets me know what I can do to limit them.


But is it realistic to expect your efforts to be able to compete with the efforts of entire communities working towards the same goals. Eclipse and NetBeans are defacto standards for IDEs these days and they have come a long way from the early days. They are also easily customized for your own specialized needs if you want.


Not surprisingly, I also like the philosophy in those articles (though admittedly I just skimmed over them -- I did bookmark them for more thorough reading later). I do see a day in the future where governments will have mandatory backdoors in all off-the-shelf computing platforms available to the general public. To the extent that I'd like to be able to maintain a modest local archive of personal data not accessible to whomever is in power at any given moment, I am confident in my ability to create a suitable system from available parts if it becomes prudent. I don't see it as an imminent threat, however.

In terms of computer languages, I don't see the world nearly so black and white as some others do. Forth and C are two different tools with some overlap. Forth does some things better on some platforms, and C does other things better. If you only have a hammer in your toolchest, then everything looks like a nail to you. But if your toolbox is full of mutually complementary tools, you can pick the one that best suits the problem at hand. I will say, however, that on the 6502 at least, I'd strongly prefer a good Forth implementation to any C compiler I've ever seen.

It's fine. I don't have time for discussion with people who can't be polite.

Well, this devolved. My own opinions:

• Familiarity and deep experience is a fine reason to stick to an architecture - both for an individual and a commercial entity.
• Commercially, products are often evolutions/spins of existing products, and "don't reinvent the wheel" can apply. As long as a CPU can keep up with the workload, incremental diffs are likely prudent over taking on a redesign for the sake of the new shiny CPU of the week.
• I don't doubt that millions or even billions of 6502 cores have shipped. It has been around a long time.
• I don't doubt that it's still chosen for new iterations of product.

So, I think I got what I was looking for - that the '816 is interesting because it builds upon the 6502, providing more features whilst allowing you to carry over your accumulated knowledge and experience. It also has its own tricks to be discovered... which adds to the fun. I guess (and don't take this the wrong way), it's like moving from an 8086 to 80286, or from a 68000 to a 68020... The same, but more.

On 32-bit architectures:

• You don't lose control or understanding with a 32-bit architecture. When I programmed ARM in assembly language I was fully in control of every aspect of execution at all times. With my commercial MIPS work, its TLB-based MMU was a extremely satisfying thing to learn and master.
• 16 million addresses is fun. But you know what's really fun? 4 billion addresses.

On 'C':

• 'C' compilers can out perform programmers. They cannot out perform expert programmers.
• 'C' is the lingua franca of embedded systems. It's a fine language for its intended task (embedded and low level operating systems) and I think it's intellectually dishonest to claim 'C' is a problem just because it's not your cup of tea.

A few years ago I needed a low cost micro to perform something fairly trivial. I chose an 8-pin PIC12, if I recall, which I programmed in assembly. I didn't chose the PIC12 for its instruction set. I chose it because it was tiny and dirt cheap. It's took a few hours to pick up the tools and ISA, and the function was implemented in a day. It was the right call.

Every CPU is interesting in its own way. Every instruction set has its interesting quirks (who doesn't love the PowerPC's eieio instruction?). And high level languages have their niche. Yes, even 'C'. Even Forth. Even Java (I just threw up a little).

I've been a lurker for a long time here, and I love that you guys continue to hack 6502. It's absurd to say the 6502 is modern in any sense, but that doesn't stop it from being special (either historically or emotionally), and it doesn't stop it being useful or being used.

Indeed. And not only is it easier to write in C than in assembly, there's also a huge existing codebase in C, including newly written libraries made by microcontroller vendors to quickly use the peripherals in their chip. Things like 3D motion tracking, audio processing, and motor drivers are all available.

Over the years, I've also written tens of thousands of lines of embedded C code, that I can fairly easily reuse from one project to the next, even switching from one ARM to another ARM or even switching from ARM to MIPS. Even all of my interrupt handlers are written in C. The only assembly language in my recent projects is for a little task switcher where I need access to the stack pointer, and some other registers/instructions that are more easily done in assembly. But that's only 100 lines of code.

My evaluation is based upon the technical merits of the product, not the financial results of the vendor. Would you rather fly in an airliner that was designed to maximize the builder's profits or maximize the safety and reliability of the product?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

@jmp(FFFA):


Er, quoting error there. I didn't write that. Could you update your post please?

-Tor

Your evaluation is based on your own biases. It is impossible for people to come to agree about what is "good" and what is "bad" and the closest we can come is to a consensus. The market's consensus is that Microsoft is good. Even among unbiased users (e.g. they don't work for Microsoft or one of its competitors) you will find that most people aren't yearning to switch to another operating system. In fact, if you look under the hood at what makes it tick, you will find quite a sophisticated operating system that is more technologically advanced in many ways than competitors like MacOS or Linux. But I didn't come here to be an apologist for Microsoft -- they don't need one anyway.

If Microsoft made an airliner, I wouldn't hesitate to fly in it. Safety and reliability are good business practices.

Any business that isn't trying to maximize its profits (within legal boundaries of course ) is by definition defrauding its stockholders.

[Edit: fixed typo]

If you were saying, for example, that familiarity and deep experience with some slightly-out-of-date technology like Freescale Coldfire, then I might agree. But for 30-40 year old technology like the 6502/65816, I don't agree. While it may be capable of performing adequately in a few modern applications, there are much better choices not just from a performance perspective, but also from a cost and efficiency standpoint -- at least for commercial applications. IMHO, if you are a developer then it is your job to keep up with technological developments in your field, even if it's uncomfortable.

In other words, keep your toolbox well stocked with tools, and try to use the best tool for each job you do, not your favorite tool.

There may be a missing element here, which is age. An engineer in their 20s should be outward looking and flexible - it's far too young to get stuck in a rut. But an engineer in their 50s or 60s might be in a position to say "this is what I know, this is what I do, and these are the people and projects that can vouch for me" and choose not to upgrade their skillset. (Or, they might feel they can't take that bet, or they don't want to!)