Well, I don't know. Does C++ on the TI-89 count as assembly? Because when a program is compiled, there is no way to tell how it was made, all you have is the executable, which is assembly code. But I guess it isn't direct assembly (although native asm can be inserted anywhere in the code if needed), and it's not really a hybrid either. Its kind of just a separate language, like a macro'd version of asm.

But it really does feel like assembly, at least for me. It uses many of the same concepts, especially optimization. In asm programming, when you use someone else's routines and just put the .inc file with your project without any knowledge of how those routines work, I would still consider that assembly. Most of the major commands in axe like variable manipulation are just shorthand for common assembly commands. Loading a variable is simply ld hl,(var) and saving to a variable is ld (var),hl for instance.

Axe language by itself is not assembly, IMHO, and same would go for 68K C and TI-Nspire C. However, since they're compiled into ASM, they're uploaded in the assembly section of ticalc.org. Same goes for GFA BASIC and ETP Studio. BBC Basic is interpreted, so it got its own section. If MLC and FastRPL ever came to fruition, they would have got their own sections on ticalc.org too.

But yeah, I agree that once an Axe program is compiled, there's no way to tell if it was done with ASM, TI-Power, Squirrelbox (in which case it has little chances to even run properly at all) or EZAsm. It ends up into ASM code, even if not 100% optimized, that can run through the Asm() command or via a shell of your choice.

Now here's a dilemma: what if somebody decided to create an Axe RPG, where he has no chance to keep his program within the 8K code execution limit? In this case, the programmer will have to rely on both an ASM lib ran through a small BASIC program to copy archived sub-programs into temporary RAM files, meaning that the game will contain a small piece of TI-BASIC. In this case, would the game need to be uploaded in the TI-BASIC section just because it contains about 1% of BASIC code?

EDIT: nevermind that last paragraph. Nikky told me that such program would still go under ASM.

Yeah, that reminds me of prgmA in Ion

Yeah I just remembered that one had TI-BASIC in it now. (Discovered after I used CODEX on it)

In all technicality, aren't TI-BASIC programs all technically ASM?

Also, I think Axe is considered cross-compiled into ASM?

Axe is assembly. End of story, debate over. It is compiled. It talks directly to the proccessor without an interpreter. It's like saying C++ programs aren't real programs because they aren't written in x86 bit ARM assembly. Come on, guys.

Excellent debating skills you have. Too bad it's misplaced (someone post the irc chatlog.) EDIT: here it is



WTF is "x86 bit ARM assembly"?

x86 ARM assembly is a generic term I'm using to reference coding for a desktop computer in assembly.

This is false. Axe may have the same capabilities as assembly, but it is not the same. There are good reasons for them to share the same directory since they both result in native executables, but they are very different from each other in terms of grammar. To use an analogy to natural languages. Assembly language is like to native English speakers having a conversation, Axe is like a native English speaker having a conversation with a native Chinese speaker who has taken English immersion courses, and Basic is like a native English speaker having a conversation with a native Chinese speaker through a hired translator. The first one is going to work great. The second will work pretty well, but the native Chinese speaker has developed different thought patterns for speaking Chinese then are used for English and so on occasion they will phrase things awkwardly when better phrasings could have been chosen. The third is going to be super duper slow because the conversation has to pass through a third party.

Is this really still being debated? The executables are clearly assembly. The source code is, well, source code. I wouldn't call C++ code assembly either even though I know it compiles to assembly, but once I have the executable, its assembly.

My point was that Axe is more like MACRO'd assembly. It's basically just a complex way of over-abusing assembly macros so that you never have to deal with all the low level stuff directly. That's why unlike C++ and other compiled languages, it still follows the assembly flow. For instance the last result from any expression is always carried over to the next expression like how BASIC uses "Ans".

Anyway, back to the phoenix topic...

Except that x86 refers to an architecture and instruction set first pioneered in Intel's 8086 cpu, and carried up through the 80286, 80386, 80486, Pentium, Celeron, Core, iN, Atom, and current chips to the present, with occasional additions. ARM, on the other hand, is another (incompatible) CPU architecture that is used in many portable devices, including the Nspire. It requires a completely different instruction set from x86, and both of these are distinct from z80.

Axe programs get compiled to assembly. The C programs I write on my quadcore desktop are also compiled to assembly. However, I don't claim they're written in assembly, because x86 assembly takes a MUCH MUCH larger skillset than writing C (I also happen to have first learned x86 ASM in 8th grade ). You could easily pre-"compile" TI-BASIC programs down into raw assembly and have them run without an interpreter, it would just be just as slow as TI-BASIC run with an interpreter. Quigibo has done a remarkable and commendable job of designing a language subset that can be pre-interpreted and compiled to a very fast form, but it doesn't make it assembly.

Actually, it would have a reasonable advantage in that the tokens would have been preparsed, and you'd only need to make the B_CALL()s that would result from each expression. Some of my recent optimization tests seem to indicate that the overhead of using more expensive operations to cut down on code size is more than compensated for by the reduction in bytes that must be parsed.



To be pedantic (and as I was explaining earlier on IRC), the executables are machine code. Assembly language is a set of mnemonics representing individual machine code operations to make it more human readable. This is why assembly language has to be assembled before being run, and why assembling is different from compiling. Compiling is an issue of language translation, assembling is a set of static transformations that is more akin to applying a cipher than it is to language translation.
When calc84maniac types raw hex into his calculator he is not writing assembly code, he is writing machine code.


Sidebar: Before anyone decides to argue further, I just spent a semester on the decidability of language recognition problems in Theory of Computation, so this is pretty darn fresh.

Actually, although it is technically machine code, it sort of compiles to assembly as an intermediate step, and then gets translated into machine code at the end. I could just as easily have the programs compile to assembly text instead of machine code. Some people have already suggested I add this feature at some point so they can hand-optimize their code a little better. I guess if I ever add that, then it would be considered assembly. Although for convenience, that would have to be done on a computer and not on-calc.

This would be equivalent to the -S flag for gcc. And what do you mean "sort of compiles to assembly"? Surely you aren't actually creating the assembly string representation of each opcode before you output it to the compiled program?

Not having experience with any of these languages, I picked a random supported proccessor from the Linux kernel page and appended an instruction set to it. Lets not try to be a stickler for the details here and loose focus on the debate at hand. My point is, just because someone doesn't code in whatever flavour of assembly their computer uses doesn't mean their binaries aren't in assembly.

No, you picked two, x86 and ARM, and mashed them together. Of course their binaries are still in machine code (see elfprince's point above) even if the user has never heard of machine code, I don't think that was supposed to be your original point. By that logic, the students in my Intro to Java class can write fast machine code for x86.

If ASM programs were written backwards, using different opcodes and such, and someone slapped MAS on it for a name, and 2 programs written in both are identical after compilation, are they both ASM?

What?

Yes, because the person writing each one had to understand ASM structure and flow, keep track of safemem in use, track the use of the stack, and such. Changing the name of the opcodes wouldn't change the concepts needed to build a program. However, abstracting routines such that you just need to string a bunch of blackboxes together without understand what happens inside _does_ reduce the number of concepts you need to understand to build a working program.

Interesting that you bring this up. opcodes are the bytes representing a machine's instruction set, not what an assembly programmer types in ASCII. Assembly language is just a set of mnemonics for opcodes, and most major processor architectures have a couple different popular styles for writing assembly. x86 for example has Intel and AT&T syntax, but they represent EXACTLY the same instruction set with no abstraction between them. z80 programmers, for historical reasons, use Intel-like syntax (because the Zilog z80 is more or less an enhanced Intel 8080: See http://en.wikipedia.org/wiki/Zilog_Z80#The_Z80_assembly_language). Even so, there are still some notational variances between various z80 assemblers even though the TI community has mostly standardized on Tasm/ZDS-like syntax, but WLA DX and ASxxxx are both z80 assemblers with different syntax.