One of the things I've noticed lately is that there is some level of language superiority among programmers. While this is not restricted in the least to members within the calculator community (programmers are actually worse on many forums that I've seen), this post was nonetheless written for that niche group.

Programming is, at it's very core, the art of writing instructions to be carried out by a deterministic machine. This is the underlying concept of programming and all languages necessarily adhere to it. It also easily defines the various levels of programming.

At the most basic level, one can program in the machine's native language of Binary (or Hexadecimal, if you prefer the easy way out). This was an extremely common form of programming in the early days of computers, but was quickly replaced by higher level logical abstractions. The first of these was the family of languages known as Assembly. Assembly essentially takes every binary instruction recognized by the underlying circuitry and replaces it with an easier mnemonic that generally describes what the instruction does that is translated to machine code by an Assembler. This allows programmers to work more quickly and easily with the logical abstractions of the mnemonics rather than the machine code. The advantage in using either of these languages is that no program can ever be performed more efficiently than by a program written in them. For any given processor, an optimal assembly or machine code program is necessarily at least efficient as a functionally identical program in any other language and often more so (in addition to being the fastest programs possible). Furthermore, all instructions on a processor are available for use (and thus all programs are possible in ASM/Hex). In many higher level languages, these instructions are not usable, which can result in much unnecessary work in writing code such as mathematical operations without machine word sizes. Of the two, Assembly language is the easier, but machine code offers some other advantages as well. For one thing, Assemblers may generate errors on otherwise valid code. Machine code will only ever return an error if the hardware (or emulator) can't handle the code. Secondly, the style of programming known as Self-Modifying Code is significantly easier in machine code than in Assembly. This often results in highly efficient programs, even above normal Assembly. Finally, Machine code has almost no "compilation" time. Whenever the code is ready to be tested, it can be copied/pasted into the executable and run.

After Assembly came the first major jump in abstraction: the compiled language. Compiled languages replace the oftentimes obscure syntax of machine code and Assembly with that of a higher level language containing instructions that don't necessarily correspond to hardware level instructions. The program which translates these instructions to machine code (called a compiler) uses routines of lower level code to synthesize these high level instructions. A good example of such a language is C. As a language, C offers a wide variety of commands and instructions in order to do many different tasks, most of which are not available directly in lower languages. This high degree of logical abstraction allows programmers to work more quickly on many common tasks and generally avoid having to program difficult things such graphics. However, contrary to popular belief, it does NOT increase portability. Compiled programs are turned into machine code, so unless they're compiled on-site by the user (often not the case), they are no more portable than an appropriately written ASM/Hex program. Compiled programs are often extremely fast, but still lower and less memory efficient than an equivalent program written by a [skilled] ASM/Hex coder.

Beyond compiled programs (which often have obscure syntax themselves) come interpreted programs. Interpreted programs are parsed at runtime by a program known as an interpreter, which contains all of the valid routines for that language. The advantage of interpreted languages is that they typically offer extremely simple syntax compared to other types of languages and even higher level instructions. However, this comes at a significant price. Since the interpreters must be kept in memory and parse the program at run-time, interpreted languages often have very high memory footprints and are generally much slower than compiled or assembled languages.

Misconceptions:

There are a few common misconceptions about these languages that I'd like to address as well.

Machine code: Hexadecimal (I'm not aware of anyone who programs in Binary) is often regarded as impossibly complex and unwieldy to program in. This is, at least in my experience, no the case. Rather, it demands a different mentality in programming than almost all other languages. Another common misconception about Hexadecimal is that it doesn't allow convenient program formatting. This is in fact not true. I offer up my own code as an example
Code:


It may look complicated and obscure, but to an experienced Hex coder (which I am not), that should be reasonably obvious as B = (A-N)*(A/N). It also demonstrates the use of comments in hex programming, something that many believe to be impossible. Use of the backspace key to remove those is encouraged before pasting into an executable.

Assembly: Assembly is often regarded as obscure and irrelevant as a language. On many programming forums, questions concerning how to do certain things in Assembly are almost inevitably greeted with at most one or two reasonable responses and a minimum of six posts saying "Why r u using that! try using ruby or c." Frankly, this astounds me as there can be very good reasons for using Assembly (good luck fitting the Python interpreter in the 4 KB of RAM on the Apollo 11 computers, buddy). However, as was stated earlier, Assembly is also the fastest possible language on a processor. That means that any other language can at most be as fast as a well written Assembly program. If Windows were written in Assembly, it'd probably run significantly faster in many places. It'd also have twice as many bugs and only come out around once a century, but those are other matters

Another common misconception of Assembly is that it's slow and painful to write. While more time is certainly spent in initial debugging, a skilled Assembly programmer can often rival a good programmer in a higher level language with most of the difference merely due to typing.

Compiled languages: Compared to ASM and Machine code, compiled languages are typically slower and less memory efficient. However, they offer significant advantages to programmers. For one thing, the nature of the hardware is much less important than it is in Assembly or Machine code. The programmer is also not required to have an intimate knowledge of many common algorithms because they are provided through routines in the language itself. Most importantly, however, they allow for relatively fast program design and the management of massive projects without getting bogged down in processor details. To use the earlier example, if Windows was written in a compiled language, it would be slower and kind of memory hungry, but come out on a reasonable release schedule and not have as many bugs. All of these are of course true since Windows is in fact compiled. Compiled languages also make problems that would be a nightmare in lower languages such as the coordination of the 3000 some processors composing IBM's Watson possible at an acceptable speed. No Assembly programmer in their right mind would hesitate to say that such a complex problem is almost always better left to a higher level compiled language.

Probably the most common misconception of compiled languages is that of "the compiler is always right." Some programmers genuinely believe that compilers produce optimal code. Frankly, that couldn't be farther from the truth. Modern compilers are extremely good at producing efficient code, but they are not and nor will they ever be (in the near future) better the task than humans. One particular case of this misconception that I remember is that of a redditor who, when faced with the challenge of designing a circuit with the minimum number of gates necessary to compute Conway's Game of Life, offered up the explanation to "just compile some vhdl with no timing and strict area constraints." The error in this suggestion should be obvious.

Interpreted languages, while conceptually similar to compiled languages, tend to occupy a niche in the programming marketplace that makes them distinct from compiled languages. One of the most prevalent misconceptions surrounded interpreted languages is that they're slow and inefficient. While this can indeed be true, many modern interpreted languages are quite fast and powerful if the considerations are adjusted properly. They typically don't achieve the speeds of compiled languages, but they're also typically higher level and thus must often deal with more computationally intensive operations than compiled languages. The main advantage of interpreted languages, TI-BASIC in particular, is that they are extremely easy to quickly mock up complex programs and algorithms in. Furthermore, the lack of compilation time makes them valuable for testing purposes. It also turns out that the lack of speed may be a good thing for many programmers' education, for there's nothing for forcing you to learn how to optimize like trying to squeeze that last bit of speed out of your quadratic solver.

Anyway, this is probably enough, as I'm pretty sure I have a giant wall of text by now...

I hear the speed argument made a lot when people are complaining about C#, and I'll basically tell people "they're also typically higher level and thus must often deal with more computationally intensive operations than compiled languages" and they'll just come back with "yeah, but it's slow". I find it better to just let people think what they will, because I won't change their mind.

As for the hex thing, I think it definitely is harder to be as clear in it as you could in something like Python. For instance, that code you put up there, you say an experienced hex coder should be able to figure it out. However, do the same thing in Python (or C#, or Java, etc.) and just about anyone can figure it out. I certainly don't agree with anyone who says it's impossibly complex and unwieldy, but it's certainly more complex and unwieldy than assembly, and significantly more so than C.

It's harder to understand Hex because you're not used to it. Personally, I find Java and C++ to be impossibly complex, but Assembly and Hex are just logical. It's all based on what you have experience with.

Qwerty, very nice post. I agree with everything, except for programming in hex. Hex, in this context, is just the hexadecimal equivalent of mnemonics, which are infinitely easier to program with imo. I don't see the point of memorizing all of the hexadecimal equivalents when you can just learn the mnemonics and what they do. Also, how would you do jumps, calls, or anything that deals with memory inside the program other than by wasting time counting bytes? It would be extremely tedious, and I think it would be difficult to maintain large projects such as Doors CS.

That may be so, but I think you'll find, in general, the barrier for entry for C++ and Java to be much much lower than Asm or hex. I do have friends who started programming in Asm, without any other languages under their belt, but I think that's rare.

The only programming I had under my belt when I started trying to learn Z80 Assembly was TI-Basic. While I have dabbled in python and lisp, and formally learned Java, I still have to say C is my favorite language to use. While Assembly gives you much finer control and allows for greater optimizations 90% of the time that isn't needed and a higher level language allows you to produce code faster and in a much more human readable format.

Also higher level languages do increase portability, all one needs is either a toolchain that supports that platform or the required interpreter on it to run that same program on multiple platforms. You cannot do this with machine code and you never will be able to. Using higher level or abstracted languages allows you to not have to worry about the native platforms hardware, OS, or API. If you call printf(); it will behave basically the same on all platforms, there is no way to do that in machine code.

That's just one of the senses in which software may be portable. While any given program written (in the case of machine code) or compiled (in the case of a compiled language) is indeed limited to the machine it was written/compiled for, you cannot deny source portability.

With most C programs, for example, simply recompiling the program is usually enough to get it to run on a completely different machine. If I were to write some code to run on my x86 PC, a simple recompile is enough in most cases to run the same code on, say, a SPARC workstation and a tiny AVR as well as the PC it was developed on. Any machine code would have to be rewritten from scratch in such a situation..

I agree that compilers cannot generate 'optimal' code in many or perhaps even most situations, but conversely, most programmers working in machine code cannot generate code that matches the efficiency of that generated by a mature compiler. While such a thing breaks down when trying to shoehorn larger languages into tiny processors (say, compiling C for a PIC14), a well-crafted compiler is much more familiar with the raw internals of a given processor than most programmers.

Considering x86 again, there are numerous factors affecting overall performance, including branch prediction efficiency, memory latency, and choice of instructions. A good compiler will, in most cases, optimize better than a human unless said human has devoted lots of time to study of the system. In effect, the compiler is a way to distribute expertise with the target system (that of the compiler author(s)) to numerous other software authors.

While I don't deny the ultimate performance considerations of machine code written by an expert with the given architecture, it's usually a waste of time, especially on modern CPUs where the user is usually the largest performance bottleneck.

Quick concrete example, using some C code compiled with gcc -g -O3 and run on an Intel Core i7:

Code:

That's my own handwritten code. I tried to make it as fast as possible, but I'm not terribly familiar with x86. Here's the same program fragment, but replacing the handwritten loop with whatever gcc wanted to generate for me (gdb disassembly):

Code:

I don't know exactly what it's doing with those LEAs, but the compiler sure does- the assembly emitted by gcc:

Code:

.p2align is the key here (the .stabn directive is related to debugging symbols), as that instructs the assembler to align the next instruction to an address that is a multiple of 16. Such a consideration would not have occurred to me, although in retrospect it will have a slight performance effect, as aligned memory accesses are faster (not just on x86 even, but most processors). The LEA instructions are just NOPs, then.

Between my suboptimal comparison operation and gcc's instruction alignment, I'd expect the generated code to be faster. It turns out that these perform just about the same, implying my code isn't that suboptimal (when I omit the countdown loop, the result is 0, so instrumentation doesn't seem to be causing a large slowdown). With the handwritten code average run time was 2634 ms with a standard deviation of 23.44, while the compiled code averaged 2629 ms with a standard deviation of 20.63 over 100 tests. I do find it rather surprising, however, how well the processor is compensating for my wasted time with the comparison inside the loop.

In both cases, I'd say the code is 'good enough', but the pure C implementation is preferred, since I didn't have to spend a while researching available instructions or wrestling with assembler mnemonics as I did while writing the pure assembly one.

I'm not saying that using assembly is inherently worse or anything, but I feel that it's a waste of time for most purposes, and my compiled programs will usually outperform the same programs were I to try to rewrite them in assembly (unless I were to spend large amounts of time studying the system).

First of all, I was not talking about interpreted languages with that statement. I was referring only to compiled languages. Interpreters provide a virtual logical machine that [ideally] behaves the same on every system.

In any case, the vast majority of computers run some form of x86 or x64 nowadays, so Assembly is pretty versatile. However, if you don't consider the native API with your high level programming, I've been lead to believe that you're likely to end up with a mess of an executable (which is really what I was talking about). Is that somehow not to case for non-trivial programs?

What do you mean by "consider native API" and mess of an executable? The only things who will be looking at the binary output are debuggers and people trying to RE the code as far as I can tell so I don't even see why a "messy" output file is an issue. If it runs and is well optimized who cares what the code looks like?

Higher level programming also allows the use of libraries which can make what would normally be non-trivial programs rather trivial. Yes libraries often vary from platform to platform but you can still shared code between different UI's. Using shared code and libraries, while possible in assembly, is nowhere near as easy as it is with compiled languages with proper OS support.

Binary and hexadacimal are *NOT* languages, you *CANNOT* program in them. They are merely how data is stored.



Assembly is just an easier way of writing machine code - binary doesn't enter the picture. Assembly is not an abstraction of machine code, it *IS* machine code, just in human-readable form instead of CPU-readable form.



Why on earth do you keep writing "ASM/Hex"? That doesn't mean anything, it is just assembly - no hex.



Not true at all. Almost all high level languages allow dropping to native code if you so desire.



Again, the two are the same damn thing. Assembly generally does go through an error checking path when assembling, yes, but it doesn't have to - that is a function of the assembler used, not a requirement.



Find me a single example of machine code being faster than assembly. You can't, because they are THE SAME THING. *ANYTHING* you can express in machine code can also be expressed in assembly. Again, the only difference between the two is the state of the data - one is human readable, the other machine runnable (machine code is also usually wrapped up into whatever platform executable is so desired, but that isn't meaningful in this thread)



Bwahahaha, you are on crack. C is absolutely more portable. You are only talking about binary portability and are dismissing code portability, but code portability is *HUGELY* important. Look at the Linux kernel - its code portability is off the charts, which is why it's used in bloody everything from embedded microcontrollers, to smartphones, to multi-billion dollar server farms.



Also not true. Compiled C programs can absolutely end up faster than assembly programs by nature of the compiler optimizations that just aren't feasible when coding by hand. For example, inlining functions or using arch-specific optimizations (if you think all x86 CPUs are the same in terms of supported op codes, you are horribly mistaken). C code isn't any less memory efficient, either, as it has no overhead. If your C programs use more memory than your assembly ones, it's because you screwed up the code, not because C uses more memory. Hence why C is suitable to embedded and kernel development, because it needs no memory itself.

EDIT: Oh, I also forgot to mention that optimized assembly actually varies between CPU manufacturer and CPU models. So fast AMD assembly can absolutely end up being slow Intel assembly - despite both being x86. Compilers can compensate for that by compiling code for specific CPU vendor models, hand coded assembly can't.



Thanks to JITs, that isn't really true. Slower, yes, but not by as much as you think.



Windows already uses a significant amount of assembly. It is used all over the place in the kernel and other speed-critical loops (just like every other kernel and driver does)



*snort*, no, they can't. Assembly *IS* slow and painful to write. Skill has nothing to do with it. Assembly is *at least* 50 times slower to write than C, which in itself is about 5-10 times slower than, say, Java, which is then 5-10 times slower to write than Python (all very rough estimates, of course)



Not true at all. Most languages have *very* few functions built into the language itself. You are confusing "common library" with "language". C, for example, really doesn't come with anything whatsoever.

We seem to have dozens of users who frequent or at least visit Omnimaga who have this mistaken impression (we mock it by saying that people are writing in the "hEx" language, after Scout kept saying "HEX is the language and hex is hexadecimal numbers"); I've been doing my best to counteract this sad sort of misinformation.

I'll post my first real response to Qwerty's original post tomorrow, though.

That being said, you could say that "writing a program in hex" is just shorthand for "writing the program using the numeric representation rather than the mnemonics". As long as we all agree that that's what it means to say "programming in hex", I don't see a problem with it, because, ultimately, there is a difference between using all the mnemonics and just straight up writing the binary file.

hmm, I liked Killer's pont on "C is absolutely more portable."
I do beleive that my microwave, phone, and toaster are programmed in C O_o

Toasters are usually pure analog devices where the only electronic part is the heating element, so I find it rather unlikely there's any software in your toaster unless it's a really fancy one. Good sentiment, though.

Screw it. The OP was designed to encourage the acceptance of non-standard languages and it's clearly failed. I suppose it was unreasonable to hope that people would understand.

Come now, you can't just except us to read what you wrote and instantly accept everything. I think it's been a nice conversation so far. Don't like the fact that Kllrnohj is a douche discourage you, that's just how he is. Rebut him! We're all just fleshing out ideas.

Qwerty, exactly what Merthsoft said. Don't get discouraged by people who enjoy arguing and debating for the sake of debating! Get in there, fight back, mix it up!

It depends on what kind of code it is. A calculator program written in C could be trivially cross-compiled on a whole bunch of platforms without any source changes, since each platform's compiler would turn it into the proper assembly variant, and a calculator doesn't really use any platform-dependent features. A C program that interfaces with hardware is not going to be so trivial to compile cross-platform.

Yes and no. It depends on the compiler in use. I think we can all agree that SDCC is a poorly-written compiler that doesn't do very good optimization, which is why people are still hand-writing z80 ASM programs for calculators.

True indeed. Even the Torque Game Engine that Freebuild runs on has sections of hand-optimized ASM.

You just lost all credibility with that statement. You're saying that Java can be up to 50*10*10 = 50,000 times faster to write than ASM? So if it takes me 5 minutes to write a simple program in Java, that it will take 250,000 minutes = 173 SOLID DAYS of coding to write the same thing in ASM with no sleep or breaks? Obviously you're resorting to massive hyperbole, and there's no point trying to address your trollpoint.

He was actually just being derogatory about his Cylon butler.

lol elfprince. @ Tari, good point as my toaster has manual dials and timers, so i guess it is probably not written in C (although, my microwave is, I swear )

makes me wonder how many other things in my house are programed in C or anything of the like..... my plastic watch perhaps? XD really makes you wonder..

Fine, only because I'm in a really pissed off mood.




Even you subscribe to the unrealistic definition put forth by most dictionaries that a computer language must be designed, then Machine code is still a language by the fact that the microprocessor opcodes are designed into the microprocessor.



I think your computer will disagree when you try to feed it ASCII ASM source as an executable file.



Since I program in pure hex, I beg to differ.




Good luck running that inline ASM from the Python interpreter in any way that wouldn't send a normal Python programmer running.



I never said that you couldn't do SMC in Assembly. It's just a heck of a lot easier to do in Hex when you can *SEE* the opcodes in use and how they have to vary.




Again, I never said you couldn't. Hex merely makes some optimizations easier to see.



And...? Personally, I write every assembly routine out in pseudo-code first. That pseudo-code works in almost every text editor ever invented, which means that my code is thus more portable than C.

If you'll actually bother to read what I wrote, you'll notice that I specifically addressed your problem in the original statement.


Um, inlining functions isn't feasible to do by hand? Did I miss a memo or something? Please tell me you're joking.

Also, if you'll examine the OP in question carefully, you'll notice that I actually described the difference between compilers and interpreters, which would imply that I know that C has "no memory overhead." In other words, that wasn't the inefficiency I was talking about.




Oh, so that's why almost every piece of software I download has a different download for AMD and Intel chips, as well as each OS supported therein?



They're not slow, but they're not blazing fast like ASM. Also, JITs still don't solve the memory issue sufficiently. I'd love to be corrected about Python on the Apollo 11 computers though.



Good to know.






Again, those libraries are part of the language, even if not in the official specification. How many of the C coders out theredo you think could re-write any of the standard libs they use so often and have the product turn out as well as the original?

I'll post another when I'm not busy with something else.