??? Isn't that longer code what you just did for dividing? In order to differentiate between what needs FPM and what needs just 16-bit or 8-bit math, you would need either a statically typed language, or use a JIT to analyze what type of an object is at execution time.

Why? Well, what type would you consider Ans to be? Its type is essentially undefined until runtime. Is A / 2 an 8-bit integer, a 16-bit integer, or a floating-point integer, and is it signed? When you do A + B, can you do the "shortcut" method of addition or must it pass through a _bcall if it is a floating-point integer? These questions cannot be answered until the program is run, or types are specifically defined for each variable.

To answer your question, the variables are standard all 8-bits, unsigned, in my first version. Later I will add 3-byte integers and signed 8- or 24-bits integers as well.

But it's time for a new update! While I had a free day, I've added all the division routines, and this page helped me a LOT, to keep the compiled result small. Now that I've implemented all the routines (without ^ , maybe I gonna remove that one because of overflow), it was time for the final last step of parsing a mathematical expression: chaining the operators. For example (A*B)+3, which would be
Code:
. I did it with leaving a special value at the stack, after adding/multiplying/whatever'ing two values. For more technical details, pm me

As always, I hope to make good progress, but unfortunately, these two weeks I have my final exams, so no free time for programming

(I read the OP, and skimmed through the first page; sorry if I missed something important.)

This looks very promising! I tend to stick to the two extremes, BASIC and assembly. Assembly is nice for speed and creating very polished programs, but BASIC is nice because it's extremely portable and I can do it without a computer handy. It sounds like this will be able to be run from a calculator to compile a BASIC program, which gives the portability and speed I'm looking for.

I do have a few questions:
1. What are planning on doing as far as differentiating signed/unsigned integers from floating point numbers?
2. You mentioned you won't be using the OS variables. How will you handle lists and matrices of varying sizes? (They may even change size within the program.)
3. Would the intended development cycle be to run the program in normal BASIC, see if it works (at all), then compile it using ICE, and then test for speed? Or would each iteration be compiled for testing. (I.e. Is there anything that would make ICE programs inherently incompatible with the BASIC interpreter, or vice-versa?)
4. (This is sort of an extension of #3.) Are there any features that would be found in ICE that don't exist in BASIC?

This will also make a rather secure way to hide the source code from other BASIC programmers (or, if you're me, lose it ).

Anyway, this looks fantastic! Be sure to keep the OP up to date with your progress.

Thanks

1. I won't use floating point numbers, like Axe don't. In ICE v1.0 you can use only unsigned 8-bits integers, and in the next version I will expand that, but not FP numbers.
2. I doubt I will support matrices, since they are basically longer lists. For the lists, they are stored at a fixed point in the RAM, and there is enough free RAM to use big lists.
3. No. ICE programs won't run with the normal BASIC compiler (neither with DoorsCE), it's very likely that they will give you an error. During compiling, I've limited error-checking, like storing to numbers, and counting the necessary Ends. After you change anything, you have to recompile it
4. Definitely. At first I gonna implement that you can manage programs, appvars and more, like the DoorsC[S]E libraries. Secondly, much more graphic routines, since it's very easy to code that. On the other side, many functions of BASIC will be lost (not the main one), but you can imagine that, like LnReg or so. I do have a list of commands here, but that one is not complete.

It looks like you didn't post about it in this thread yet; on IRC, you proposed the following two possible header formats, where {i} is the imaginary i, sqrt(-1):
Code:
To make it easier to detect whether a program is ICE source code, and to make it easier for you to parse descriptions to boot, I propose:
Code:
In fact, you might want to consider a third option as well:
Code:

I dont think the source code should have an icon. The compiled executable, yes, but the source code, no.

I don't think the icon would be for the source, but for the compiled program.

Yes but look at axe. There's a parser flag ('#icon()') to set the icon of the program. Also axe can compile to any shell, as well as nostub. If axe is told to compile for no stub (for example) it will ignore the #icon flag becouse no stubs cant have icons.

Small post despite my final exams: I've 'implemented' an API. That is, when running ICE from an ASM program, it will skip the header and directly search and compile the program. An example would be this:

Code:

Of course, you can modify it for your own, but the program name should be in OP1 and to skip the ICE header, increment twice the starting data point.
My ICE program would look like this:

Code:
etc

Soooo, I found some bugs with the logic operators
Now I've created this table, and I wanna ask you if you can try to optimize any of these code snippets somehow, either in speed or size
Thanks in advance!


Code:


EDIT: this is for unsigned numbers, and register A should contain 1 if true, and 0 otherwise

I believe "dec a \ sub a,(hl)" is faster than "scf \ sbc a,(hl)", but at the very least it is more readable. (And it should still set the carry flag the same way.)

I think calling this a compiler for CE-BASIC would be misleading at this point. It would be its own runtime environment.

Nope. What if A=0 and (HL)=0? My code would result in A=-1 and the carry flag set. Your code sets A=-1 too, but not the carry flag set.


This.
Is.
A.
Compiler.
For.
CE-BASIC.
It reads the program data, and compiles it to ASM, and stores it to a program. It doesn't run the program or whatever.

You have stated multiple times of implementing breaking changes in ICE:


CE-BASIC programs will not compile on ICE if they use FP math, and ICE programs will not run on CE-BASIC interpreter if they call special ICE methods. Therefore, ICE compiles ICE programs, not CE-BASIC programs.

This sounds accurate, however, to the best of my knowledge, ICE programs will be made essentially the same as CE-BASIC, which means ICE would essentially be compiling CE-BASIC programs, since that's what they will be before compiling... The user would make a CE-BASIC programs and then compile it, therefore, it compiled a CE-BASIC program, even though this one might not be syntactically correct because it was made to be user with ICE compiler, it still had the header, and I think that's the very definition of a CE-BASIC program.

A language is defined by both its syntax and semantics. Even if the syntax of ICE is nearly or exactly identical to TI-BASIC, its semantics certainly are not. And I believe only a relatively small subset of the BASIC commands will be supported. So ICE is definitely its own language and should not be advertised to compile/interpret/whatever TI-BASIC, although such can be advertised for a TI-BASIC-like language.

I'm very happy to say that parsing a mathematical expression is almost done!
It now 'chains' operators, i.e. A*B+3, instead of the seperate routines for A*B and A+3 for example. Out of the 14 booleans/operators (+ - * / or xor and -> => <= > < = !=) I've finished 10. I only need >= <= > < to do, and after that, I'm ready with parsing such string (yet without functions). I haven't implemented auto-opt yet, but I will definitely do. Here is an example of what it can do:
String = A+4*B/(1-C)+3
Output =
Code:
The only good optimization I see is replacing the "push af" with "ld h, a" and remove the "pop hl".

Hello guys!
I've worked insane hard to get all the stuff done, and now everything works! Any order of operators will work (the order like the OS does...), and I'm now implementing functions, like ClrHome, Asm(<string>, If, Repeat, While, Lbl and Goto. This is my to-do list for ICE v1.0
Version 1.0.0: June XX, 2016
☑ Adding, substracting, multiplication, dividing
☑ Parenthesis
☑ Booleans, comparisons
☑ Storing, variables
☑ Run inline ASM
☑ Display integers
☑ ClrHome
☑ If, Repeat, While
☐ Lbl, Goto

I DID IT!!!!!!!!!

I'm so happy now I succesfully compiled a normal program, without any errors

Ofc, I've finally a gif for you guys!


The program is still far from perfect, but I'm more than happy with this now

EDIT:

Congrats! Great job on this wonderful tool i am sure to use many times in the future.
When will it be uploaded to the archives, do you think?