Rather than judge the language on its preliminary release how about we wait until its major bugs are fixed?

C sucked too when it was first released because the compilers were slow and had poor optimizations. Now look where C (and C++) are today. The compilers are very efficient and produce good code. Give the maker of this language a break.

Yes but C also had the intel, AT&T, Microsoft, Borland, IBM, GCC guys all looking at the code for about 20 years. I may of missed a few names but that's a lot of smart people, a lot of money and a lot of time working on fixing c and c++. If the language is strong in it's roots people will adopt it and make it better. If it stinks in it's roots people will not use it and it will not get better.

By the time C came out, it was already the third generation of languages that DMR had played with. By the late 1970's at least, it was already a decent language to use. By then, the language proper was mostly set in stone. This was all before Intel, IBM, Microsoft, and GCC guys got involved (AT&T was involved from the beginning).

Yes but C was on pre-X86. So someone had to write the new C and C++ compilers to support x86 and get the code to run fast. The language may not have changed, but neither has the concept of a car either. Just under the hood has changed.

Finally, someone's saying this... You're right, version 1.0 of any major program is never usually worth using anyways - wait until the author(s) have been given more time to work out the large bugs, add more basic features, etc. I have to admit that multiplication and division should have been among the first things added in the first place, but still, as long as they're implemented in a later version, who cares?

With a project of the magnitude of creating you're own compiler I would expect version 1.0 to be significant. But read the comment written by Gergely Patai, the problem is bigger than a lack of multiplication or division: it isn't even functional.

So a suggestion for the author of this program is that until he can distribute a sample project with the compiler (a simple testris or phoenix clone) that compiles out of the box, there should only be beta releases on tinews.

What do you mean when you say it isn't functional?

Gergely Patai reported this code/errors:
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;
}

a SLIGHT change in the code to this: (basically just put the word declaration outside of the main loop)

#include "text.ads"
#define TI83_PLUS

word a, b;

void main() {
a = a + b;
if (a > 100) { b = 5; } else { b = -100; }
}

and it compiles completely and WITHOUT ANY ERRORS.

Maybe you should read the tutorials better before you start complaining?

Pardon me, the tutorial DOES talk about the possibility of declaring local variables. Besides, even with this modification it generates wrong code, repeating the very same errors I'm talking about.

"the possibility of declaring local variables" - true, but none of the examples declare words as local variables, not sure if that matters (tho it shouldn't, but not declaring local variables for the time being isn't THAT big of a deal to get around)

and the code compiled/loaded/ran just fine on my TI-84+SE.....

So are you implying that straying away from the examples voids the warranty? What program did you compile? What version of SquirrelBox are you using? I'm talking about the one currently available to the public, which generates invalid assembly, no matter how nicely I put it.

Not at all, but in early stages, i think is a good idea to stay close to the recommended.

I used the compiler on the website, i used the .jar executable, not the applet version, and i added .disp() before and after "a = a + b;" so that i would know wheather or not it was executing right (i do not know any assembly, so far i have only programmed in ti-basic). That was the only change to the code, and then i used TASM to compile, and ti-connect to send it to my 84+SE, and it ran just fine, and did exactly what it was supposed to do. I do not know why it doesn't work for you, but it works just fine for me, that is all i know.

I am not apart of the developement team, i merely saw it posted on the front page, so i checked it out. I do not have "behind the scenes" access to a newer version, nor did i change the source code.

I see, it means you added 0 to 0, and the result was 0, right? Try this then with the necessary disps added:

word a, b;

void main() { a = -1000; b = 2000; a = a + b; a = 20 + b; }

TASM has the tendency of simply ignoring invalid instructions and assembling anyway--a bad habit--, but it should give a warning ('unrecognised argument' or something). It is okay if you don't know asm, but you could still read the output of the assembler. Anyway, if you don't understand the code, why are you telling me it's flawless?

Also, just for your information, even code copied right from the tutorial doesn't compile, not even by SquirrelBox's standards.

"Anyway, if you don't understand the code, why are you telling me it's flawless?"

I believe I only said that it worked, not that it was flawless.

"Also, just for your information, even code copied right from the tutorial doesn't compile, not even by SquirrelBox's standards."

That's because he screwed up when doing the tutorial. Rather than saying

"#define TI_83PLUS", you should use the .ads file called ti83plus.ads (i think thats the name, i'm not positive) as "#include "ti83plus.ads" - since that has "#define TI_83PLUS" in it AND the necessary header information.

I will try that code when i get home and let you know....

this code:

#include "ti83plus.ads"
#include "text.ads"

word a, b;

void main() {
.ClrHome();
.HomeUp();
a = 1000;
.Disp(a,1,1);
b = 2000;
.Disp(b,2,1);
a = a + b;
.Disp(a,3,1);
a = 20 + b;
.Disp(a,4,1);
}

Generated this ASM:

.nolist
#include "ti83plus.inc"
.list
.org userMem-2
.db t2ByteTok,tAsmCmp

func_main:
B_CALL(_ClrScrnFull)
B_CALL(_HomeUp)
LD HL,1000
LD (global_a),HL
LD A,1
LD (CurRow),A
LD A,1
LD (CurCol),A
LD HL,(global_a)
B_CALL(_DispHL)
LD HL,2000
LD (global_b),HL
LD A,2
LD (CurRow),A
LD A,1
LD (CurCol),A
LD HL,(global_b)
B_CALL(_DispHL)
LD HL,(global_a)
ADD HL,(global_b)
LD (global_a),HL
LD A,3
LD (CurRow),A
LD A,1
LD (CurCol),A
LD HL,(global_a)
B_CALL(_DispHL)
LD A,20
ADD A,(global_b)
LD (global_a),A
LD A,4
LD (CurRow),A
LD A,1
LD (CurCol),A
LD HL,(global_a)
B_CALL(_DispHL)
RET

global_a: ; word a
.DB 0,0

global_b: ; word b
.DB 0,0

.END
.END

Which errors out in TASM, don't know why

line 0027: unrecognized argument (HL,(global_b))
line 0036: Unused data in MS byte of argument. (9d)

For the simple reason that there is no add hl,(xxxx) or add a,(xxxx) instruction. Even if there were, the code wouldn't work properly, because it uses byte arithmetic where words are needed (and it isn't hard to create the reverse situation).

in 1.3 it now compiles just fine. try it out

Well, this seems to interest people.. I'm only disappointed QASM had no fan base. I can't get squirrelbox to work and am not sure if we can include asm code withinj the C-style sources... Back to my QASM rant - see link - it was limited, yes, and had a strict syntax, but was otherwise flawless and very useful for newbs. Of main importance: it was easy to expand with macros and supported asm code within sources -> all for personal optimization :-) I'll have to learn this new one long enough to get frustrated, then resort back to pure z80. These "high level" asm languages are NO MORE THAN A STEPPING STONE to the true beauty of pure bit-by-bit coding. BTW: few projects sadly ever seem to go past v1.5, even by the best authors. Good luck to Dan Cook :-)

I believe that by simply placing a @ before whatever ASM you want to run is acceptable (thats how the Disp commands are set up, they are merely links (or whatever the proper term is) to the ASM code in the text.ads include - i believe thats also how they plan to expand the current command support)

just so ya'll know, 1.2 is now out...(1.1 came out yesterday, 1.2 came out today to address a few minor bugs that poped up)...

its still just OK, but looking better

I STRONGLY urge everyone to try this out again. A vast majority of the bugs have been fixed, and it is functioning just fine now. One of the bugs came from the .Disp macro, so it has been split into 2 seperate ones now, DispWord and DispByte (same syntax as before).

This code that i posted that didn't work:

#include "ti83plus.ads"
#include "text.ads"

word a, b;

void main() {
.ClrHome();
.HomeUp();
a = 1000;
.DispWord(a,1,1);
b = 2000;
.DispWord(b,2,1);
a = a + b;
.DispWord(a,3,1);
a = 20 + b;
.DispWord(a,4,1);
}

now compiles and runs just fine (no TASM errors either)...

Much better, but it still confuses bytes and words in expressions; there is no real coercion management. In that very example you posted it uses byte addition to calculate the sum of 20 and b (and swapping the factors results in an illegal instruction too). Also, subtraction of words requires clearing the carry flag before performing SBC, obviously. The most fundamental error is probably using the F register in calculations (also resulting in invalid instructions) when you have parentheses in expressions. Indirection is also problematic, since the program will easily try to store an address in a byte, overwriting the following variable. Using the dereference operation kills the compiler with a NullPointer exception.

I'm sure this is far from an exhaustive list of bugs, as these are only the most obvious ones.