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

Indeed. High-level languages aren't really meant to be just as fast as asm. They are meant to make programming easier and quicker.

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

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)

Quote from: DJ_O on February 18, 2013, 01:15:54 pm

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

[...]
Some TI-BASIC code by Weregoose (I think someone posted code on IRC or a post somewhere once) looks even more complex

Since when is Weregoose code redbale

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.

Quote from: Hayleia on February 18, 2013, 01:24:45 pm

Quote from: DJ_O on February 18, 2013, 01:15:54 pm

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

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)

Quote from: DJ_O on February 18, 2013, 01:15:54 pm

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).