[TI-84+CE] ICE Compiler

[PT_]

Hello everyone!

I can imagine many, many people are waiting for this post, but yeah, one must be the first to start such project
I want to introduce this program:

ICE - an interpreter/compiler of CE-BASIC

Hooray! It would look like Axe Parser, but then for the newest calculator, the TI-84+CE.
Now are there many people who have questions, about what is possible with it, how long would it take to complete, what are the pros/cons?
Let me answer some questions.

What is ICE?
ICE is an interpreter/compiler of CE-BASIC. Normally, the OS reads a BASIC programs, and compiles it to some ASM commands, and then execute it. ICE does almost the same, but only read it, and compiles it to ASM commands, but instead of executing, it stores them into another program! In that way, you can turn your BASIC program into an ASM one, which is 1000x faster.

Why ICE?
Because I want to make a cool project (and not only games), and I think this program would be very useful for many people, so I decided to give it a try

What is possible with ICE?
I've no details yet, because I'm in an early stage, but I want to make it possible to keep it as BASIC as possible. I mean, you should be able in the future to compile all the BASIC programs to ASM. I never gonna reach that.... Like Axe Parser, it doesn't work with the TI-OS variables, because they are sloooowwwww. Instead, all the variables are in the RAM.

What are the pros and cons of ICE?
You can compile almost all the BASIC programs to ASM, which is 1000x faster. Since the CE has a memory-mapped screen, I'm going to implement a bunch of graph routines as well. A disadvantage is that you're a bit limited with the BASIC commands. I hope I can explain this later

When will you finish it?
In these weeks, I'm busy with school stuff, so I can't really do something with programming. But after that, I hope to finish it as fast as possible. Depending on the difficulties, I hope to finish it in some monts

How works ICE?
The hardest part is to express a string (and eventually store it to a variable). I will implement the Shunting-Yard-Algorithm for that (I will explain later). Once I got that ready, I need to write routines that replaces BASIC commands, like ClrHome would be call _HomeUp / call _ClrTxtShdw or whatever. Once THAT is ready, or enough of them, I will release a beta `

How smart is ICE?
For now, it is pretty smart, and by "smart" I mean, that if you display 2 strings which are exactly the same, it will be only once in RAM, an example:

Code Select Expand

Disp "ICE","ICE"
would be this:

Code Select Expand

   call _NewLine
   ld hl, _pointer_disp_0
   call _PutS
   call _NewLine
   ld hl, _pointer_disp_0
   call _PutS
   ret

_pointer_disp_0:
   .db "ICE", 0
which saves some RAM.

Example of Shunting-Yard-Algorithm:
Let's say I have this code:

Code Select Expand

F/2+3->A
The algorithm converts this to:

Code Select Expand

F 2 / 3 + A ->
Now I gonna read this sentence, and convert it to this (for example code)

Code Select Expand

   ld a, (address_of_variable_F)
// Now I now that I need to divide A by 2, which is a power of 2, so just rotate the byte
   or a
   rra
// Now to add 3, which is a value, not a variable
   add a, 3
// Now store it to variable A, so
   ld (address_of_variable_A), a
This is basically how the algorithm works, but then a bit more complicated especially when you have a long string.

Progress:
As some of you may know, it's very hard to work in ASM . That is why I decided to first create this in PHP (that's why I asked how to read .8xp with PHP). After I finished that, I will port it to ASM. I'm now in the stage for developing the Shunting-Yard-Algorithm, which is the main and hardest part.

I know,  there are still a ton of questions, so feel free to ask anything if you don't understand it, or whatever you want to say!


Psst, don't mind my English, I'm only a sweet Dutch boy


Originally posted on Cemetech: https://www.cemetech.net/forum/viewtopic.php?t=12616&highlight=






Current version: 1.2.1
========DOWNLOAD========
Download ICE Compiler

[Snektron]

Interesting project. I've had a few stabs at a CE language too, with C using a parser generator called leg (http://piumarta.com/software/peg/peg.1.html)
A few obstacles i encountered were:
- i wanted to ideally use the ZDS routines. Due to the register arguments they take (HL and BC) it became impossible to do a proper precedence based expression
compiler, since it would need complex register allocation or a lot of useless swaps
- A CE lang would need to be compatible with other C routines, which would add the problem of types.
- I got frustrated with the C SDK since the makefile makes a lot of mess.

I've implemented a non precedence based expression compiler, which works.

What types of variables are you going to implement? floats, ints or ti's floats?

im interested in how this will turn out

[PT_]

Interesting project. I've had a few stabs at a CE language too, with C using a parser generator called leg (http://piumarta.com/software/peg/peg.1.html)
A few obstacles i encountered were:
- i wanted to ideally use the ZDS routines. Due to the register arguments they take (HL and BC) it became impossible to do a proper precedence based expression
compiler, since it would need complex register allocation or a lot of useless swaps
- A CE lang would need to be compatible with other C routines, which would add the problem of types.
- I got frustrated with the C SDK since the makefile makes a lot of mess.

I've implemented a non precedence based expression compiler, which works.

What types of variables are you going to implement? floats, ints or ti's floats?

im interested in how this will turn out

Yea, that is why I started with this project, and I hope to make good progress within weeks!
Like Axe, I'm going to work with ints, and MAYBE with floats, but then only for numbers, and not lists or eventually matrices.

But a difference is, that you get an element of L1, you need this: {L1+5} or whatever. I will just allow L1(5), like BASIC programmers already do

[Snektron]

Oh that a nice idea. You should keep the {...} notation though, for Axe programmers and else you'd need to something weird to get other locations

[PT_]

Oh that a nice idea. You should keep the {...} notation though, for Axe programmers and else you'd need to something weird to get other locations

That sounds good, but if I'm right, it's hard to do operations on lists, such as L1+5. That is why I keep it close to BASIC, so people doesn't need to learn many new things if they aren't familiar with Axe

[DJ Omnimaga]

I saw this on TI-Planet and Cemetech and I like the idea of a new language like BASIC or something similar to Axe. As I saod on TI-Planet, the best idea would be to implement the most popular commands first, so that it's not a burden for you, especially if it's one of your first projects.

The other thing I would suggest also is to use integers instead of floating points, both for the reason above and the fact integers are much faster and smaller.

And yeah thanks for the cross-post. A lot of people here were into Axe Parser and wanted a similar language for the CE. People here tend to also be more open-minded towards such language, given how popular Axe was, so I wish you good luck with ICE.

Also don't worry about your English. Most of us speak French and Dutch as main language (only 1 staff speak English as native language)

[PT_]

I saw this on TI-Planet and Cemetech and I like the idea of a new language like BASIC or something similar to Axe. As I saod on TI-Planet, the best idea would be to implement the most popular commands first, so that it's not a burden for you, especially if it's one of your first projects.

The other thing I would suggest also is to use integers instead of floating points, both for the reason above and the fact integers are much faster and smaller.

And yeah thanks for the cross-post. A lot of people here were into Axe Parser and wanted a similar language for the CE. People here tend to also be more open-minded towards such language, given how popular Axe was, so I wish you good luck with ICE.

Also don't worry about your English. Most of us speak French and Dutch as main language (only 1 staff speak English as native language)

I will definitely use integers, both 1-byte and 3-byte. I've yet no idea how to determine whether it's 1 or 3 bytes, but whatever 
On the other side, while I spoke with someone at Cemetech, we figured out a nice way how to determine whether it's a BASIC or an ICE program. The first line of the program-to-compile would look like this:
i<target_program_name>i, with the imaginary i of Ice

[DJ Omnimaga]

Hm, 3 bytes integers is not something I hear about everyday. Most of the time people use 1, 2 and 4 bytes integers and I even saw people use nibbles. 1 byte is too small for most purposes, but can still be handy. Axe uses 2 bytes by default for variables and is more versatile. 4 bytes is much larger, but still smaller than floating points, but I guess that 3 bytes wouldn't hurt for size and it's still allow numbers from 0 to 16777215 anyway (as unsigned integers).

Also yeah, it's better to have something to check if the program is ICE or BASIC, just like we had with Axe. I forgot how Axe did it, but I think programs had to start with .PRGMNAME but it's best to avoid using that syntax in case one day they decide to port Axe to the CE and use the same check.


Also what would be nice about the language is if it allowed us to change the screen bitrate (and color palette when needed), as well as displaying LCD content from any location in the LCD RAM (eg for fast scrolling).

[Snektron]

3 bytes since the eZ80 uses 3 bytes instead of 2 bytes . Thats why the CE doesnt need paging like Z80 based calculators which could only index 65536 locations.
So it would actually be slower to use 2-byte ints. (Unless ofcourse you'd put the calculator in Z80 mode)

Btw, is this an open source project?

Also how are you going to handle parentheses in your algorithm? will ((((((((((3*2)))))))))) + 3 become

Code Select Expand


push hl \ push hl \ push hl \ push hl \ push hl \ push hl \ push hl \ push hl \ push hl \ push hl
ld hl, 3
ld bc, 3
call _imuli
pop bc \ pop bc \ pop bc \ pop bc \ pop bc \ pop bc \ pop bc \ pop bc \ pop bc \ pop bc
ld bc, 3
add hl, bc

?

[PT_]

Hm, 3 bytes integers is not something I hear about everyday. Most of the time people use 1, 2 and 4 bytes integers and I even saw people use nibbles. 1 byte is too small for most purposes, but can still be handy. Axe uses 2 bytes by default for variables and is more versatile. 4 bytes is much larger, but still smaller than floating points, but I guess that 3 bytes wouldn't hurt for size and it's still allow numbers from 0 to 16777215 anyway (as unsigned integers).

Also yeah, it's better to have something to check if the program is ICE or BASIC, just like we had with Axe. I forgot how Axe did it, but I think programs had to start with .PRGMNAME but it's best to avoid using that syntax in case one day they decide to port Axe to the CE and use the same check.


Also what would be nice about the language is if it allowed us to change the screen bitrate (and color palette when needed), as well as displaying LCD content from any location in the LCD RAM (eg for fast scrolling).

Indeed, the ez80 has 3-byte registers, so I will use that too. Then people could just work with 2-byte values, like they always did.
I believe I already said it, but I'm going to implement a bunch of graph routines.

3 bytes since the eZ80 uses 3 bytes instead of 2 bytes . Thats why the CE doesnt need paging like Z80 based calculators which could only index 65536 locations.
So it would actually be slower to use 2-byte ints. (Unless ofcourse you'd put the calculator in Z80 mode)

Btw, is this an open source project?

Also how are you going to handle parentheses in your algorithm? will ((((((((((3*2)))))))))) + 3 become

Code Select Expand


push hl \ push hl \ push hl \ push hl \ push hl \ push hl \ push hl \ push hl \ push hl \ push hl
ld hl, 3
ld bc, 3
call _imuli
pop bc \ pop bc \ pop bc \ pop bc \ pop bc \ pop bc \ pop bc \ pop bc \ pop bc \ pop bc
ld bc, 3
add hl, bc

?

I think the PHP version would be open-source, but the ASM version not.
For your second 'question', you might want to take a look at how the Shunting-Yard-Algorithm works. It filters out the parenthesis, so it will become 3*2+3

[Snektron]

You i only just realized that problem only occurs when using shunting yard. I should implement shunting yard

Still, the problem remains when doing something like 3 + 4 * 5, but i guess then you can use push:

Code Select Expand


ld hl, 3
push hl
ld hl, 4
ld bc, 5
call _imuli
pop bc
add hl, bc


[PT_]

You i only just realized that problem only occurs when using shunting yard. I should implement shunting yard

Still, the problem remains when doing something like 3 + 4 * 5, but i guess then you can use push:

Code Select Expand


ld hl, 3
push hl
ld hl, 4
ld bc, 5
call _imuli
pop bc
add hl, bc


Nope
With my algorithm, it first calculates 4*5, and then add 3.
Second, it knows when to use either 3-byte or 1-byte registersregisters. In this case, the most likely is 1-byte, so it will look like this:

Code Select Expand

ld h, 4
ld l, 5
mlt hl
ld a, l
add a, 3
I don't know if this is exactly what it will look like, but that is my target

[c4ooo]

Interesting project. I've had a few stabs at a CE language too, with C using a parser generator called leg (http://piumarta.com/software/peg/peg.1.html)
A few obstacles i encountered were:
- i wanted to ideally use the ZDS routines. Due to the register arguments they take (HL and BC) it became impossible to do a proper precedence based expression
compiler, since it would need complex register allocation or a lot of useless swaps
- A CE lang would need to be compatible with other C routines, which would add the problem of types.
- I got frustrated with the C SDK since the makefile makes a lot of mess.

I've implemented a non precedence based expression compiler, which works.

What types of variables are you going to implement? floats, ints or ti's floats?

im interested in how this will turn out

Yea, that is why I started with this project, and I hope to make good progress within weeks!
Like Axe, I'm going to work with ints, and MAYBE with floats, but then only for numbers, and not lists or eventually matrices.

But a difference is, that you get an element of L1, you need this: {L1+5} or whatever. I will just allow L1(5), like BASIC programmers already do

Maybe ile take a stab at making an on calc c-compiler later, good luck to you!

Well in axe {L1+foo} is not a list. L1 is just a number that point to an arbitrary memory address. 

Maybe ile take a stab at making a C compiler later, good luck to you!

[MateoConLechuga]

Interesting project. I've had a few stabs at a CE language too, with C using a parser generator called leg (http://piumarta.com/software/peg/peg.1.html)
A few obstacles i encountered were:
- i wanted to ideally use the ZDS routines. Due to the register arguments they take (HL and BC) it became impossible to do a proper precedence based expression
compiler, since it would need complex register allocation or a lot of useless swaps
- A CE lang would need to be compatible with other C routines, which would add the problem of types.
- I got frustrated with the C SDK since the makefile makes a lot of mess.

I've implemented a non precedence based expression compiler, which works.

What types of variables are you going to implement? floats, ints or ti's floats?

im interested in how this will turn out

What are you talking about? The makefile is literally a drop-in replacement. Also, registers are preserved on calls, so it is just a simple matter to either do it inline or put all your assembly into a .asm file (Which is also compiled in with the toolchain.) Multiple files are also sanely handled, so I have no idea what you mean by the makefile is too hard Unless you are doing things completely wrong, using the SDK is a piece of cake. Please explain.

[Snektron]

I'm not really a fan of how everything is just spewed in one directory, and not in some proper folder like src/ and build/. I made my own makefile for that but it broke.

Also the register thing had nothing to do with the SDK. It had to do with the way i wanted to do expression compiling, where + and - would operate on hl (so you could use
add hl, bc and sbc hl, bc). * and / would operate on BC, so you could use something like call mul_bc_de. Then the constants would get loaded into de.
It would produce quite short code, but i also wanted to use the RTL functions, where __imuls takes arguments hl and bc and thus ruining my algorithm