Omnimaga
General Discussion => Other Discussions => Miscellaneous => Topic started by: harold on February 18, 2013, 11:27:44 am
-
High level languages make many things harder instead of easier, I'm sure most assembly programmers feel the same way, especially when I show you what I mean.
So you want the full result of a multiplication. That's non-trivial on z80, but on x86 (and many others) you can get this in one or two instructions.
But now you're working in a high level language again and guess what, it won't let you do that. You could perhaps use a type that is twice as wide.. unless it was the widest type already. So you have to split your numbers and multiply the parts separately. To make matters worse, your compiler isn't detecting the idiom, and what should have taken 5 cycles or so now takes more than a dozen. Wow.
Ok but at least that was solvable and the performance may be acceptable. But now you want to do a 64bit modular multiplication. What's the problem, just mul\div, right? (assuming the inputs were already reduced). But of course that relies on 1) a full multiplication and 2) a full division. Not gonna happen. So now what, do a multi-word division? You can.. but it's complex and slow and bug prone, and it's something that's supposed to take 2 instructions.
Non-standard extensions to C/C++ solve this, but what if you're working in C# or Java? There are, afaik, no good solutions. (no, using bigint isn't a good solution, if anything it's worse)
Let's add some more, there's a ton of stuff like this.
Say you want to take the average of two unsigned numbers. Easy, right? Just add them and rotate-right-with-carry by 1.
Oh wait, you don't have a carry, because this is a high level language. Solutions range from "absolutely horrible" to "wrong", except perhaps for "average = low + ((high - low) / 2)" which I suppose is just about acceptable.. but I still have this nagging feeling of "but it should be simpler!". I suppose a smart compiler can detect this idiom and do the right thing anyway, but it's vexing.
Or do a multi-word addition/shift. There are various ways to calculate the carry, but you're still forced to jump through hoops just because there's no "add/shift with carry".
Or, you want to find the index of the lowest/highest set bit. Simple. Even in Java, though I wouldn't trust it to compile to the right thing. But in C#? Nope. You'll have to write something complicated and/or slow to emulate it.
Rotates. Ok there is "(x << n) | (x >> -n)" and the likes of it, and then hope&pray the compiler isn't an idiot (C and C++ compilers generally aren't idiots with this, but once again C# loses). It could have been so simple. Say, >>> and <<< operators. Though of course Java already used >>> because it doesn't have unsigned types (worthy of a whole separate rant, especially the fact that bytes are signed). Do you even need rotates? Yes. You do.
-
Yeah, I felt this way many times with Axe. One good solution, though, is to use a high level compiled language (Axe/C/C++) with some assembly mixed in every now and then. That way you get the best of both worlds. It's what I do.
-
Yeah, I felt this way many times with Axe. One good solution, though, is to use a high level compiled language (Axe/C/C++) with some assembly mixed in every now and then. That way you get the best of both worlds. It's what I do.
Yeah, I usually end up mixing in assembly to make things work faster. I often do this for programs that don't allow you to extract the remainder and integer part from a division x.x
-
In C# and Java, optimization is by design not intended, the important was to have the same binary to work on every plateform using a virtual machine, at the cost of some speed. In C, yeah you can optimize stuff, but it's kinda hard to translate well into the most optimized binary code. Again, high-level languages such as C were intended to make life easier by coding in something that looks more like natural language. So if you want to save every byte to the max you'll better want to make it directly in assembly.
-
Indeed. High-level languages aren't really meant to be just as fast as asm. They are meant to make programming easier and quicker.
-
Yes, but the examples I gave are not only slower in high level languages, they're harder to do. And that's just, well, contrary to the purpose of those languages.
-
Yeah, I felt this way many times with Axe. One good solution, though, is to use a high level compiled language (Axe/C/C++) with some assembly mixed in every now and then. That way you get the best of both worlds. It's what I do.
???
You call Axe a high level language ??
-
On the other hand, there are most likely examples where ASM programmers will find it harder to do in high-level languages than ASM, but high-level language programmers will find the same thing harder to do in ASM. In some cases it depends of mentality or preferences really and what you have been used to for years (eg if you never programmed in TI-BASIC and jumped straight to Z80 ASM, you might find TI-BASIC code structure nightmarish). This is why some people claim that ASM is easy to learn and use even though many people have tried hard and failed, and of course there are people who say BASIC is easy to learn and use even though others found it a major pain in the butt to use.
In conclusion, both low and high level languages are vexing, but in different ways :P
And Hayleia I would say Axe is semi high level, because it has several commands that have identical syntax (or close) to TI-BASIC, which is an high-level language. In 2010, I wrote a screen inverting program using pxl-On commands that only required swapping X and Y coordinates around and adding an Axe header in order to be compilable. At the same time it is low-level too because of the whole pointer access and how much control you have on the RAM. I would say it's a mix of both.
-
On the other hand, there are most likely examples where ASM programmers will find it harder to do in high-level languages than ASM, but high-level language programmers will find the same thing harder to do in ASM. In some cases it depends of mentality or preferences really and what you have been used to for years (eg if you never programmed in TI-BASIC and jumped straight to Z80 ASM, you might find TI-BASIC code structure nightmarish). This is why some people claim that ASM is easy to learn and use even though many people have tried hard and failed, and of course there are people who say BASIC is easy to learn and use even though others found it a major pain in the butt to use.
In conclusion, both low and high level languages are vexing, but in different ways :P
True all of this :)
And Hayleia I would say Axe is semi high level, because it has several commands that have identical syntax (or close) to TI-BASIC, which is an high-level language. In 2010, I wrote a screen inverting program using pxl-On commands that only required swapping X and Y coordinates around and adding an Axe header in order to be compilable. At the same time it is low-level too because of the whole pointer access and how much control you have on the RAM. I would say it's a mix of both.
Well in Basic, you can't even do 2→A→B while in Axe you can do this:
Select({BB^8+GDB0},→{Q+++AA^64*12+(BB/8→r3)+L6→}) xor |pi|11111111
→{r3-11??r2-11,r2+1}
Yes it has structures but not immuable structures, optimization is still very possible and there is a lot of liberty :)
(edit: sorry if my sentences mean nothing)
-
Like in C, you still have the best of both worlds by using inline assembly.
-
And Hayleia I would say Axe is semi high level, because it has several commands that have identical syntax (or close) to TI-BASIC, which is an high-level language. In 2010, I wrote a screen inverting program using pxl-On commands that only required swapping X and Y coordinates around and adding an Axe header in order to be compilable. At the same time it is low-level too because of the whole pointer access and how much control you have on the RAM. I would say it's a mix of both.
Well in Basic, you can't even do 2→A→B while in Axe you can do this:
Select({BB^8+GDB0},→{Q+++AA^64*12+(BB/8→r3)+L6→}) xor |pi|11111111
→{r3-11??r2-11,r2+1}
Yes it has structures but not immuable structures, optimization is still very possible and there is a lot of liberty :)
(edit: sorry if my sentences mean nothing)
Some TI-BASIC code by Weregoose (I think someone posted code on IRC or a post somewhere once) looks even more complex O.O
-
And Hayleia I would say Axe is semi high level, because it has several commands that have identical syntax (or close) to TI-BASIC, which is an high-level language. In 2010, I wrote a screen inverting program using pxl-On commands that only required swapping X and Y coordinates around and adding an Axe header in order to be compilable. At the same time it is low-level too because of the whole pointer access and how much control you have on the RAM. I would say it's a mix of both.
^ That.
IMO, Axe is a lot closer to C than asm because of its syntax and ease of use. OFC, you have a lot more control over RAM, but that's because on a multitasking computer, you can't mess with stuff a lot 'cause you may cause a general crash (btw C has pointers). On calcs, your program is the only process that's running, and even then you can't mess with the OS data unless you know what you do. ;)
-
[...]
Some TI-BASIC code by Weregoose (I think someone posted code on IRC or a post somewhere once) looks even more complex O.O
Since when is Weregoose code redbale :P
So, I myself like lua, php and C++, i just like all the stuff you can do with it, and you can still do the other stuff with it, you just need to work a bit around, you could write yourself functions in a file and include it in any project you use.
-
Yeah the principal force of C is that it has pointers, with that you can edit arbitrary points in memory easily and have a lot of flexibility.
-
And Hayleia I would say Axe is semi high level, because it has several commands that have identical syntax (or close) to TI-BASIC, which is an high-level language. In 2010, I wrote a screen inverting program using pxl-On commands that only required swapping X and Y coordinates around and adding an Axe header in order to be compilable. At the same time it is low-level too because of the whole pointer access and how much control you have on the RAM. I would say it's a mix of both.
Well in Basic, you can't even do 2→A→B while in Axe you can do this:
Select({BB^8+GDB0},→{Q+++AA^64*12+(BB/8→r3)+L6→}) xor |pi|11111111
→{r3-11??r2-11,r2+1}
Yes it has structures but not immuable structures, optimization is still very possible and there is a lot of liberty :)
(edit: sorry if my sentences mean nothing)
Some TI-BASIC code by Weregoose (I think someone posted code on IRC or a post somewhere once) looks even more complex O.O
I am not talking about complexity but about calculating in calculations. You will never be able to write this in basic:
Line(8,+1→A,,*2)
In Basic, you'll have to write:
9→A
Line(8,A,A,A*2)
And Hayleia I would say Axe is semi high level, because it has several commands that have identical syntax (or close) to TI-BASIC, which is an high-level language. In 2010, I wrote a screen inverting program using pxl-On commands that only required swapping X and Y coordinates around and adding an Axe header in order to be compilable. At the same time it is low-level too because of the whole pointer access and how much control you have on the RAM. I would say it's a mix of both.
^ That.
IMO, Axe is a lot closer to C than asm because of its syntax and ease of use. OFC, you have a lot more control over RAM, but that's because on a multitasking computer, you can't mess with stuff a lot 'cause you may cause a general crash (btw C has pointers). On calcs, your program is the only process that's running, and even then you can't mess with the OS data unless you know what you do. ;)
"Ease of use" depends on what you are doing ;)
For example, with nikitouzz we challenged ourselves to make an optimized code, and we had to never use any command that is "easy of use", only elementary commands. This is where I got the previous line from (with the Select).
-
I am not talking about complexity but about calculating in calculations. You will never be able to write this in basic:
Line(8,+1→A,,*2)
In Basic, you'll have to write:
9→A
Line(8,A,A,A*2)
Psh, in BASIC you just do:
9
Line(8,Ans,Ans,Ans+Ans
-
I am not talking about complexity but about calculating in calculations. You will never be able to write this in basic:
Line(8,+1→A,,*2)
In Basic, you'll have to write:
9→A
Line(8,A,A,A*2)
Psh, in BASIC you just do:
9
Line(8,Ans,Ans,Ans+Ans
True, but then, you didn't store 9 to A :P (even thhough that would only recquire one more line).
-
As far as Language levels are concerned:
*Axe is as low as you get without BEING assembly. It barely has function support.
*C is one of the lowest level languages you will see on the computer. Most compilers even allow inlined assembly.
*C++ is stupid for this list. It's C with Java attached, and it shows.
*TI-Basic is interpreted. Badly. It also doesn't have enough features for me to give it a decent "Level", as it has no Object oriented anything, no functions, nothing a programmer would WANT in a High Level Language. However, it also abstracts ridiculously from the assembly it takes to run it.
Not that I don't agree with you on your points. The best part: These problems are perfect examples of where that horrible quote "You can't beat the compiler" is completely false. The compiler will NOT optimize anything like this, for the same reason Hayleia pointed out: It can't read your mind. It doesn't know if you want that 9 in Ans or not, so it has to assume the safer answer. An optimization that's not guaranteed to work is a bug, and people don't like bugs.
One idea I had, actually, sort of regarding to that specific type of problem: A program that goes through compiled code and determines where it CAN go. It follows through all branch instructions, tracing every line of code it runs, keeping track of which stored values are read from, and reports the results. This would also be useful for reverse-engineering binaries to identify data structures.
-
C++ came before java, and you can do inline asm with it on most compilers.
-
No offense, but I think some of you are not getting the point: the things I listed are harder to do in high level languages (not just less efficient), which is completely the opposite of the idea behind those languages - they're supposed to make things easier than if you were working in assembly.
You either need some hack like inline asm or compiler-specific intrinsics (that is still harder than it would have been, or at the very least not easier), or you can't even use either (C#? Java - to a point. at least it has some interesting stuff in the Integer class).
-
Some things are harder, but the point is to make the language look closer to English, making it easier to learn. Once you learn ASM, it is easy to use, but it is much easier to learn C# or java initially. You have to sacrifice some of the low level things in order to simplify programming.
-
I would agree, but all the problems I named are easily solvable by just providing the relevant functions in the standard library. That doesn't make the language any harder to learn.
-
I'm probably also not quite hitting what you're getting at, but i've tried many many times to get into high-level languages but i just can't. I get bored, lost, don't understand concepts, or just find that the code looks super ugly (pretty silly excuse, i know ;)). With a new assembly language (z80, m68k, SH3/4, ARM) i can usually spend a couple days rummaging through the manual and things just click together. I really enjoy learning what the processor can actually do. Maybe it just seems easier when i know exactly what's going on? I generally prefer to write my own code as i dunno why but i don't like using libraries. I hate feeling dependent on libraries, i'd rather just write the routine myself or pull it from a routine i've already written(/can modify if i want to be more efficient in my program). I guess high-level languages just seem much bigger and much more complicated/confusing to me... And besides, i think the way assembly addresses memory is generally much simpler (and C code seems to super abuse the stack). I love finding my way around an assembly program, even in assembly languages i've never used before like old SNES (65816) and (especially) NES (6502) code, but i hate trying to read C code :P Assembly just makes more sense to me...
-
As far as Language levels are concerned:
*Axe is as low as you get without BEING assembly. It barely has function support.
*C is one of the lowest level languages you will see on the computer. Most compilers even allow inlined assembly.
*C++ is stupid for this list. It's C with Java attached, and it shows.
*TI-Basic is interpreted. Badly. It also doesn't have enough features for me to give it a decent "Level", as it has no Object oriented anything, no functions, nothing a programmer would WANT in a High Level Language. However, it also abstracts ridiculously from the assembly it takes to run it.
I agree with Axe and don't know the other languages :P
But that post is still interesting for me to know which language I am most likely to choose if I ever want to program for other things than calculators :)
-
I would agree, but all the problems I named are easily solvable by just providing the relevant functions in the standard library. That doesn't make the language any harder to learn.
I think jwalker's point is that assembly commands are just 2 characters long, followed with registers and/or digits and absolutely no english, making the language look like gibberish to anybody who's used to seeing languages like C, Java, TI-BASIC. Just this alone is enough to make the examples you specified harder to do in ASM for some people.
Also I think to debate languages everyone should put their ASM fanboyism/elitism stuff away (or any other language for that matter). Because someone loves a programming language or is experienced with it doesn't mean that language is flawless/superior in every way possible nor that it's factually easier/harder to use.
-
Also I think to debate languages everyone should put their ASM fanboyism/elitism stuff away (or any other language for that matter). Because someone loves a programming language or is experienced with it doesn't mean that language is flawless/superior in every way possible nor that it's factually easier/harder to use.
Harsh :)
You know I never said that, right.
I like C#, I think it's a nice language with a clean syntax and I work with it much more than I work with assembly, it (and it's not alone in this) just has this problem that some things are made harder than they should be, even though it would have been trivial to fix many of the problems in a way that in no way compromises the language. And I gave specific examples of cases that are particularly vexing. No generalizations.
-
I know that C++ came before Java :P I'm just trying to make an analogy.
-
I would agree, but all the problems I named are easily solvable by just providing the relevant functions in the standard library. That doesn't make the language any harder to learn.
I think jwalker's point is that assembly commands are just 2 characters long, followed with registers and/or digits and absolutely no english, making the language look like gibberish to anybody who's used to seeing languages like C, Java, TI-BASIC. Just this alone is enough to make the examples you specified harder to do in ASM for some people.
Also I think to debate languages everyone should put their ASM fanboyism/elitism stuff away (or any other language for that matter). Because someone loves a programming language or is experienced with it doesn't mean that language is flawless/superior in every way possible nor that it's factually easier/harder to use.
Exactly what I am saying. Also I think some of the reasons that those things aren't in the languages is, they are great on a low level basis, but how much do you actually need them in a high level language?
-
Also I think some of the reasons that those things aren't in the languages is, they are great on a low level basis, but how much do you actually need them in a high level language?
Exactly. I don't fully understand how you'd want high level languages improved. Full low-level access? Or implementations of everything you could do with those low-level things in the standard library? You'd still find missing things. Some languages are by concept just not well suited for solving some problems, and there's often a reason why.
-
Exactly. I don't fully understand how you'd want high level languages improved. Full low-level access? Or implementations of everything you could do with those low-level things in the standard library? You'd still find missing things.
A bunch of the ones that are take the most effort to implement. Just because it won't be complete doesn't mean it can't be better.
You need that modular multiplication to implement Miller Rabin. Do you want to argue that C# is not well suited to testing whether a number is prime? It's not some scripting language.. you're supposed to be able to do real things with it.
But anyway none of this is really to the point. The point is, it's vexing.
Also, this is derailing completely.
-
Yeah, I felt this way many times with Axe. One good solution, though, is to use a high level compiled language (Axe/C/C++) with some assembly mixed in every now and then. That way you get the best of both worlds. It's what I do.
...and then a major compiler like MSVC++ drops inline assembly on AMD64 targets. Unfortunately even mid-level languages like C/C++ can't always get low level enough.