\/\/007! I can now port my guess the numbar game to ALL calculators!
*Evil Laugh*
Try to stop me now!!!!!!!!!!!!!

No you can't, then it wouldn't be "Guess the Numbar in ASM" anymore ;-)

\/\/4C|<Y F|_||\| R4|\|D0/\/\ |\||_|/\/\84R 93|\|3R470R 5|-|411 R|_|13 41\/\/4Y5 4|\|D 43\/3R!!!111111

(anyone's up for porting WFRNG to casio and hp calcs?)

Let me clear up a few things. First, the compiler is done, but the language is being developed; imagine C++ without any includes. If you want to help, see the link a few posts up (thanks Patrick).

Also, to compile for any calc you have to say so in your code. For example:
#define TI83_PLUS
means compile this code for the TI-83+. Any generic code will compile and work on any calc, and for those things that will not, preprocessor commands (aka "directives" I think) can be used to compile code differently in different cases, like to define the same macros/functions that use calc-specific rom-calls and other stuff to work how they need for each calc.

Another thing is that ADSMBLG (for short) does work with characters and strings; character values and byte values are treated the same (since they are stored the same), and string values can be embedded into arrays. The end result is that you can use string and character values in the same way that "plain old asm" can :-)

Btw, thanks MV for posting a news item for it :-)

I think you should have tested this thing before the actual release. First, I couldn't even get it to run without recompiling, and I don't think the majority of people is willing to install the JDK just for this purpose. However, the most important issue is that the compiler simply produces erroneous code. Try to compile this, and you'll see:

void main() {
word a, b;
// This results in an invalid instruction
a = a + b;
// And this results in a compilation error...
// ...unless you write b instead of a?!
// But then the compiled code contains
// -101 instead of -100?! (And uses bytes anyway.)
if (a > 100) { b = 5; } else { b = -100; }
}

It is much too early to show the public. :(

You could write a review.
But be sure to update the review when this program is updated.

How efficient is this language? Is it as efficient as ASM? And if not, is it more efficient than TI-BASIC?

As a proud member of the Antidisassemblage Development Team, I too would like to clear a few things up. First of all, the language is in its earilest stages of development. Many people are gawking at the fact that there is no multiplication, division, floating point, etc. However, the article did not mention that a massive effort is currently underway to develop the language to the point of usability. The potential for any of these missing operations is present because assembly code can be directly inserted as a "macro" of sorts inyto your source. This means that although some primitive types and operations are not yet defined, they will be availible in include files VERY SOON. Let me repeat that: MULTIPLICATION, DIVISION, FLOATING-POINT, STRINGS, ETC. ARE GOING TO BE SUPPORTED IN THE VERY NEAR FUTURE. It was unfortunate that the author of the article had to present this project's negative aspects so blatantly; we have put a LOT of effort into this project and we don't want to see it fail because users were discouraged by a biased article. Email me at jon_p @ sbcglobal.net (no spaces - those are antibot) for more information or visit our site (web link) and sign up to be a member of the group.

right, I'm a member too. I've been folowing the emails, though not replying, and this will all be resolved very soon. This is the first major release, cut some slack, this is from scratch.

Right, glad you're clearing that up. I read through the Planned Features part of the documentation and didn't see the things you mention here, so I assumed it wasn't being worked on. Nice work otherwise.

On the project, do you have any use for someone with 2 years professional Java and C# experience? I'm afraid I don't know z80 ASM, but I am very familiar with C, and my college computer science classes have been in C++, so I know it rather well also, though I haven't touched it in a while. Hey, maybe you need a website for the project... I self-employ myself selling PHP/mySQL driven web software... I'm sure you could use a dynamically manageable project site for documentation, latest releases, etc. :) (free of course) Let me know if you're interested.

Yeah, in looking at your site again, you could use something like that :D I might even be able to host you if you don't mind a URL like antidissasemblage.paulygon.net

I'm not directly responsible for the site @ the moment, but I can say with almost 100% certainty that Dan would scream "yes!" to both of your offers. (Especially since most of the responsibility will be left with me in a few weeks, when Dan goes on a mission for 2 years.) Perhaps the easiest way to dicuss this would be for you to join as a member of the current site and to discuss it through the group's posting system.

Oops, I mean YOUR offer...

I signed up for the list serve, but I'm not getting any messages, and the letter I sent doesn't seem to be getting any replies. Whats the deal?

Wait a minute, even the current features are too buggy to move on. You should clear up the core before building around it.

No matter what, I'm still going to be a hardcore asm coder, but this looks great and I'll definitely try it out! Once the multiplication/division and the other stuff is added, this could be the ultimate language for writing really large programs like RPGs - it'll have most of the advantages of assembly, but with a syntax abstract enough for writing tons and tons and tons of code without getting lost.

The problem I see is that most assembly programmers can write more optimized code than this language will tend to produce. If you tried to write a huge game, it might become too large, faster than if you had done it entirely with assembly.

So... I see this language as both quite an impressive achievement on the author's part, and as a tool for beginning assembly programmers, with which they can learn how concepts translate into real assembly code. Who knows? Maybe it will help avoid things like my year-long-wait before releasing an assembly program!

OK... Will the compiler build flash apps? I'm too lazy to download it...

I've been an object oriented programmer for 5 years... and I get lost in "Hello World" asm programs. The learning curve is just too high for me.

How can you be just an "object orientated programmer"?
OOP is pretty much merely a way of bundling blocks of "normal" code into classes. Surely it's not much of a problem to be able to jump out of that frame of mind?

Where I study computer science, the programming courses (which do not require any previous programming experience) teach stuff from the very beginning (Hello-world-ish at first), and then progress to eventually cover objected oriented programming. I've been a practicum assistent for the specfic course which teaches object oriented programming, and I can tell you that many people have quite some trouble jumping into that frame of mind.
Whether the earlier courses, the environment we use or OOP itself is to blame I cannot say, but I can assure you that (especially for people with not too much experience) it's quite a leap. I'd suspect the other way around will also be quite a leap, especially if you've got to teach yourself.

Ah, there's a huge difference between being taught computer science and learning how to program. The two are often mutually exclusive! :-D
For example, I have recently been working on a website which had clearly by someone who had been taught that OOP was The Best Thing Since Sliced Bread and had written an entire website (albeit a very simple one) using OOP in PHP. The result might have looked very snazzy but it was an absolute nightmare to maintain and utterly confusing.
I wish people wouldn't teach that OOP is different to a straight-forwards "script-like" language. They're not, really, if you think about it. That's my major beef with Java - it forces an OOP style when in a large number of cases it just ends up complicating issues.

I beg to differ. In an OOP language, not everything has to be done in classes. I use Python (which is OOP), and hardly ever use objects. At least in the way Python does it, it can create less cluttered code.
Here's an example:

class Greet(object):
[t]def hello(self):
[t][t]print "Hello"
[t]def Bye(self):
[t][t]print "Good Bye"
*Note: This is Python code, so "[t]" means a tab.

See? That's not that hard to understand, and it adds to the reusability of the code.
What if I had a game with lots of the same sprites?
Well, I could just create a sprite object and call it as it's needed.
I don't see what the big deal is about OOP.

OOP is useful, there's no doubt about it. However, it can (and does) get misused. Being taught nothing but OOP tends to mean that people have a tendency to wrap everything in classes - so when your PHP script extends a class that handles adding to the database that extends a class that selects a table which extends a class that selects a database which extends a class which connects to a database (which could be done in about 3 lines of PHP anyway) you start to get a little annoyed.

I like OOP, yes. I don't like inappropriate and excessive use of it, that's all.

Python and C++ are not OOP languages in the sense that Java is OOP. They support OOP ideas, but do not enforce them.

You're right about the Python, although the Python Docs contain lots of unnecessary classes and crap.
I wish people would use it the way it was intended.