Do you actually need to extract the first three characters as a substring, or are you merely interested in checking if it starts with a specific three-character-long string?

---

If it's the latter, Matrefeytontias is partially correct in suggesting that there's a command for that. The Equ►String() command checks if two strings passed as arguments are equal, returning zero if so and nonzero otherwise. The reason why he's only partially correct is because, as you can see from that description, the command isn't made to check if one string starts with another. But if you're comfortable using the technically undefined return value when the strings aren't equal, you can check this. With the current implementation, when the two strings differ, the return value is actually a pointer to the first character in the second string that differs from the character at the same position in the first string. So the following code would work to check if a string starts with "PTR", but isn't guaranteed to work in future versions of Axe:

"PTR"→Str0
!If Equ►String(<string>,Str0)?-3-Str0
.Starts with "PTR"
End

For reference, the second line is an optimized version of:
If (Equ►String(<string>,Str0)=0) or (Equ►String(<string>, Str0)=(Str0+3)).

---

If it's the former, extracting a substring of predetermined length is somewhat straightforward, despite Axe lacking a built-in substring command. Extracting a substring simply comes down to copying the characters you want to a new area of memory and making sure the new substring data ends with a null terminator byte. So to extract a 3-byte substring from the front of a string, you'd need to reserve 4 bytes of memory and copy it, perhaps like this:

Copy(<string>,L₁,3)
0→{L₁+3}
.Substring at L₁


Request: change the "Full View" option to "Pop-out", or add it as a new option. Full view mainly seems useful when you want a separate OmnomIRC window to look at, but this:



Seems cluttered and not as nice as this:

Okay, I think I've implemented a fix for the A=-64 behavior. Grab the new code (I made a number of changes, so I'd recommend just re-grabbing the whole thing) and try again?

Whoops, I think I see where I went wrong. Try changing jr c,Mul_A_DE_Custom_ANeg64 (third instruction after Mul_A_DE_Custom_ANeg) to jr z,Mul_A_DE_Custom_ANeg64 and see if that fixes it, at least partially.

Before I try my hand at this, is there some distribution that can be expected of the input values? Because if you really want this micro-optimized, any input tendencies should be known so they can possibly be taken advantage of.

Quote from: Runer112 on June 09, 2014, 02:42:30 pm

Quote from: Eeems on June 09, 2014, 02:17:44 pm

Quote from: Runer112 on June 09, 2014, 01:19:13 pm

And a helpful reminder: in all of these cases, make sure the string always ends in a zero byte before you try to perform any operations like display or length(), or the results could be quite unexpected!

But buffer overflows are fun!

That aside, have you ever thought about writing some advanced documentation on how Axe works at a lower level? I'm sure many people would find the deeper knowledge they could glean from that quite useful.

That sounds like it would take a lot of time and effort, which is probably why I haven't ever thought about doing it. But I tend to leave these mega-posts in lots of question topics, going way more in depth than was asked. Maybe all of my mega-posts could be compiled into some semblance of what you describe.

Somebody should do that

I can't definitively say that this is the only factor causing the issue, but I do definitely see a large factor:

""->Str0

Due to the challenges and costs that would be entailed by dynamic memory allocation, strings and other data types that might seem like they should be dynamically sized are in fact not. They will only have as much space available as you allocate for them.

In this case, you've allocated enough memory for a string of length zero (which is actually one byte, due to the zero byte that marks the end of the string). As you can imagine, this is not particularly useful, and as soon as you start trying to "append" to this string, you start overwriting whatever comes after it in memory. If you try to "append" the string "HELP", the 'H' will overwrite the zero byte that marks the end of the string, and the characters 'E', 'L', and 'P' will overwrite whatever three bytes come next in memory. In this case, they happen to be the next three bytes of data in your program: the first three bytes of the string "Unknow command" (Side note: the correct spelling is "unknown"). So when you later try to print that string, the first three bytes have been overwritten with "ELP" and that's what you see.

The usual way to fix this is to allocate a fixed size for the string buffer ahead of time (and don't allow the string to go over that size). There are three primary options:

• Allocate the buffer inside the program with something like Buff(256)→Str0. Note that this will not work if you compile your code as an application, and that Buff( is really the det( token renamed.
• Allocate the buffer externally by using a free static RAM reference like L₁ in place of Str0, or make Str0 refer to the reference, like L₁→Str0. As long as you can find the free RAM space for it, this is generally the preferred option. Note that you do not perform any active allocation; the "allocation" simply entails making a note that nothing else should be trying to use that area of RAM at the same time.
• Allocate the buffer externally by asking the OS to allocate space for the buffer at runtime, like GetCalc("tmpBUF",256)→S. Note that since this is allocated at runtime, you have to save the reference in a variable instead of a static pointer like Str0. This may also fail if the space cannot be allocated due to not having enough free user RAM (in which case S will be zero), a problem which does not affect the other two options. tmp is really the w token (2nd+9), added in Axe 1.2.0, which results in the variable automatically being deleted when your program finishes.

If you want a dynamically-sized string, you can do that by either storing it in an OS variable and resizing it, or using the OS edit buffer. Both are much more complicated options, and unless you absolutely cannot use a fixed-size buffer, I would steer clear of them for now.

And a helpful reminder: in all of these cases, make sure the string always ends in a zero byte before you try to perform any operations like display or length(), or the results could be quite unexpected!