Qwerty.55 wrote:
Kllrnohj wrote:
Qwerty.55 wrote:
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).
Binary and hexadacimal are *NOT* languages, you *CANNOT* program in them. They are merely how data is stored.
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.
Quote:
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.
I think your computer will disagree when you try to feed it ASCII ASM source as an executable file.
Quote:
Quote:
Why on earth do you keep writing "ASM/Hex"? That doesn't mean anything, it is just assembly - no hex.
Since I program in pure hex, I beg to differ.
Quote:
Quote:
Not true at all. Almost all high level languages allow dropping to native code if you so desire.
Good luck running that inline ASM from the Python interpreter in any way that wouldn't send a normal Python programmer running.
There are ways to call C libraries from Python and C can have inline assembly, done.
Quote:
Quote:
Quote:
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.
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.
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 what? Pseudo-code has nothing to do with this argument be cause it cannot be made to run on anything, it isn't code. If your ASCII representation of hexadecimal representations of machine opcodes was so great to program with why even bother with pseudo code, oh yeah because higher level programming languages abstract things so that the code is quicker to write and easy to understand.
Quote:
Quote:
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.
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.
Quote:
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.
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?
There is a reason the Gentoo Linux Distribution was so popular for a while, it allows people to compile their software for their specific CPU and chipset allowing the compiler to make speed optimizations that cannot be done if the code has to be run efficiently on many different processors.
Quote:
Quote:
Quote:
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.
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.
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?
As for C library's there is example code or pseudo code available for all of the standard C library routines so I'm sure most programmers could come up with something that would work. But anything past the standard libraries were written by other programers and I have seen in the past if you don't know how a library works or how you could accomplish what it does yourself you will most likely have a hard time using it to its full extent. Just because Java provides many data structures in its standard libraries doesn't mean one can use them effectively or even know when best to use which one without knowing how to implement those data structures themselves.