I believe that to no longer be universally true. An assembly language guru may still be able to beat a compiler with some regularity, but see the linked example:

http://courses.cs.washington.edu/course ... ssalin.pdf

This is for the 68k, and there are similar methods that can be applied to other architectures, maybe even the 65xx. I would have a hard time betting against our dclxvi and a handful of others (myself not included), but I believe that modern cross-compiler technology might even have a fighting chance against them, if it was brought to full-focus on the 65xx platform (although that would be unlikely at this stage of the game)!

Mike B.

Yeah, cpx/cpy usually are used in lieu of the accumulator if you have something in there you want to keep. Thanks for running the analysis!

With regards to compilers: As stated earlier, in modern machines, CPU's are just a mirage of what's actually happening under the hood: register renaming, branch prediction, cache behavior, etc. etc. On the other hand, I have yet to see a modern compiler to create some really clever 8-bit code.

As an aside, I talked to a guy who worked for an embedded company and when I asked him what he worked on, he said 8051's and 6502's! Happily surprised to hear they're still in use!

-Yvo

I expect good compilers can produce better than a good assembly-language programmer only if we're talking about one of the very complex processors whose assembly languages are not user-friendly. The 6502 is not one of those though, which is one of the reasons we are attracted to it. Like Icy said, "65x02 is wonderful. [...] It is natural, logical, it doesn't give you headache." (Take the "&start=6" off the URL to see the beginning of the forum topic.)

There are times in embedded control however when you simply must know and control the amount of time a piece of code takes. No choice. If you know your compiler well enough to know that, you might as well write in assembly, unless the compiler can tell you for sure how many clock cycles it will take, or you want to look at the compiler's output.

We use relays in our equipment for lower distortion in situations where it has to pass a signal in the normally closed state if it loses power. I've had other situations in test equipment where solid-state relays couldn't cut it, for various reasons of distortion, controlling voltages far outside the power supply rails, etc..

_________________
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 agree on that. Processing deadlines cannot be met with consistency if the programmer has no direct control over the instructions used to produce the desired result. Subtle timing issues about which the compiler might not know can only be resolved to their best-case outcome by a skilled assembly language programmer who is cognizant of the number of clock cycles required to complete each instruction. This is why a few device drivers for MC68K and x86 MPUs are written in assembly language, not C.


Despite all of the advances in solid state switching technology, relays and contactors continue to be the preferred choice when guaranteed action under all foreseeable conditions is demanded. As I earlier noted, this is especially the case in railway signalling, where a failure that results in a CLEAR or APPROACH signal display when it should be STOP can set the stage for a disastrous wreck.

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

I have spent all of my adult life involved in automotive electrical systems diagnosis and repair (with an occasional engineering opportunity thrown in), and I can state unequivocally that a demand for "guaranteed action under all foreseeable conditions" is an invitation for eventual disappointment, regardless of the nature of the hardware involved. In the last 30 years I have seen just as many bad mechanical relays as I have solid state relays, possibly more, due to their ubiquity. S**t happens, no matter how well you design and implement a system.

Mike B.

Most electrical parts in automobiles are designed to be inexpensive to manufacture and easy to install, and often, reliability becomes a secondary consideration during the design phase. Also, the life expectancy of automotive electrical components is seldom more than 10 years, although they do often last longer than that.

The components used in railroad signalling equipment, locomotive and subway car traction control circuits, and similar, are designed to be trustworthy under conditions that would destroy most automotive equivalents, and are generally rated for upwards of 20-25 years of service. While failure is not unknown, it is remarkably infrequent. Naturally, there is a price to be paid for such a product.

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

Are relays used for logic in your world BDD, or just for switching loads? Are relays used for sequencing? I'm wondering if you are a short distance or a great distance from relay-based computing.

In railroad signalling, relays are used for logic as well as load switching, as the logic is usually not real complex. Also, a purely electromechanical control system is less likely to fail in an unsafe way than a solid state or hybrid system.

In electric traction applications (locomotives, trolley cars, etc.), there is usually a mix, with contactors handling the traction motor loads and various solid state devices tasked with handling intermediate loads and control functions. It depends to some extent on the desired degree of isolation between the control functions and the high current loads.

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

They have been saying that for at least 30 years. At least. And it still is rather questionable. Back in the 80's I was paid to do 6502 assembly programming and the reason I got the jobs was because I beat the compilers. Not until a compiler deduces it should (re)create a SWEET-16 to optimize down non-time critical code will I begin to entertain the vague possibility that maybe, just maybe, the compiler writers are approaching something credible.

I also wrote DSP code for super Harvard architecture processors and I never saw a compiler that could make a good decision about what data to place in each of the data memories. Again assembly programming was the larger part of the code and in fact all of the interesting parts of the code.

The only possibility where a compiler has an edge is for truly troglodytic processors such as the stuff grunted out by Intel. Just how many prefixes do they use these days?? Z80 had a few prefixes, 6809 had two I believe but both were reasonably easy to keep track of. 6502 and 1802 used none. I am not sure there were others. 1804 / 1805 added a single prefix but still left a few things to be desired. 6502 never added any though I think one prefix for 16 bit extensions on memory operations (say decrement a 16 bit zero page location) and long branches (useful for relocatable code) would have been worth it.
Ah yes. Those were the days, my friends, we thought they'd neeever end.

You might enjoy this demo of a tic-tac-toe machine built in 1968 which has a 4-bit CPU built from relays. It can be seen at the Museum of Communications in Seattle. (For those on this side of the Atlantic, Harwell's WITCH can be seen at the National Museum of Computing in Bletchley.)

Harwell's WITCH was quite the contraption, and was derived from the work of seminal computer scientist Maurice Wilkes. I wouldn't mind see it up close. Lots of relays! Imagine the racket it would create whilst computing.

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

It's quite a nice noise actually. There's a topic over on anycpu.org about David Anders' recreation of WITCH using modern electronics to emulate the dekatrons - I've posted a few videos over there for anyone who wants to hear it.

On instruction frequencies, see this later topic on dynamic instruction frequencies:
viewtopic.php?f=1&t=4132

They'll continue saying that compilers are or will be smarter than humans until the end of time, and it'll continue be every bit the load of bupkis it still is today. It's only ever approached being true if you limit it to sufficiently uneducated humans and assume they can never learn new tricks - which is, y'know, kind of the exact thing humans are best known for doing. But in actual fact, I've never heard of an optimizing compiler doing anything that a human being can't learn to do and then apply more intelligently.

Save for the human actually consuming and processing the large data sets that the modern compilers can consume during static processing of large programs.

Also consider runtimes such as the JVM that will switch from interpreted to compiled to recompiled based on runtime behaviors. The JVM will compile code to an "optimal state" based during a specific run of the code. Code may well be revisited during the life span of a java program (notably large servers). Early "done once" java code won't be compiled at all, as it's run and done and "fast enough". Later, "hot" code gets converted from byte code to compiled machine language with an early "best guess" on data flows. Later, as more data is processed, that code can be re-compiled with better data to make the code even more efficient for the processing at hand (inlining more procedures, inverting logic to better support processor pipelining, etc.).

Meanwhile, the programmer is mostly isolated from much of this. The mantra is "write solid Java code" as this is the kind of code the optimizers best understand in terms of capturing developer intent, rather than craftier, "this will be faster" code.

The issue here is not that a human can't do something in isolation, but the modern compilers and runtimes have access to much more information about not just how the code is written, but also how it is actually used within any specific instance of a program, and even to the CPU family the code is being run on.