Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
Download ICE Compiler here:

ICE Compiler




Hello everyone!

I can imagine many, many people are waiting for this post, but yeah, one must be the first to start such project Wink
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 Smile

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 Smile

How does ICE works?
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 Smile`

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:
Disp "ICE","ICE"

would be this:

Code:
   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:
F/2+3->A

The algorithm converts this to:

Code:
F 2 / 3 + A ->

Now I gonna read this sentence, and convert it to this (for example code)

Code:
   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 Razz especially when you have a long string.

Progress:
As some of you may know, it's very hard to work in ASM Razz. 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! Smile
Oh wow this looks awesome PT_! Shock I can't wait to use it!
PT_ wrote:
Hello everyone!

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

ICE - an interpreter/compiler of CE-BASIC

[...]

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! Smile


Two tips, from someone who's done a lot of work with parsing and compiling.
A) you want to start developing an elaborate test suite, to make sure your program output reproduces the ground truth of the TI interpreter
B) PHP will make you cry. There are numerous tools that will make your life a lot better (I would recommend ANTLRv4)
elfprince13 wrote:
<snip>
Two tips, from someone who's done a lot of work with parsing and compiling.
A) you want to start developing an elaborate test suite, to make sure your program output reproduces the ground truth of the TI interpreter
B) PHP will make you cry. There are numerous tools that will make your life a lot better (I would recommend ANTLRv4)

I don't really understand your tips.
A) Do you mean that a mathematical expression gives the same result with ICE as the OS?
B) I'm creating this in PHP, because I'm familiar with it, and then I have the possibility to create a website for converting files.
I wish you luck in this ambitious project.

I heard that one of the major obstacles to writing a BASIC compiler for the z80 series was the slowness of the bcall--doesn't it take like 1000 cycles? Are calls on the CE fast enough that these BASIC commands can be significantly sped up?
lirtosiast wrote:
I wish you luck in this ambitious project.

I heard that one of the major obstacles to writing a BASIC compiler for the z80 series was the slowness of the bcall--doesn't it take like 1000 cycles? Are calls on the CE fast enough that these BASIC commands can be significantly sped up?

Thanks! Smile
CALLS are totally different from BCALLS. With bcalls, there are much more stuff to do, before actually executing the ASM. Link Calls just jumps to a location in the OS, and there it directly executes the ASM, and then returns to the location where you call them.
(Correct me if I'm wrong Razz)
PT_ wrote:
elfprince13 wrote:
<snip>
Two tips, from someone who's done a lot of work with parsing and compiling.
A) you want to start developing an elaborate test suite, to make sure your program output reproduces the ground truth of the TI interpreter
B) PHP will make you cry. There are numerous tools that will make your life a lot better (I would recommend ANTLRv4)

I don't really understand your tips.
A) Do you mean that a mathematical expression gives the same result with ICE as the OS?

And in general, any program fragment should give the same result. Having a comprehensive suite of tests will really make your life easier in debugging when differences do crop up.


PT_ wrote:
B) I'm creating this in PHP, because I'm familiar with it, and then I have the possibility to create a website for converting files.

I would recommend at the very least drawing up an ANTLR4 grammar and using their visual grammar debugging tools to get a parse tree of some sample input files. This will have two benefits. First, it will force you to formalize your intuition about how parsing TI-BASIC should take place in a cleaner setting than checking flags in whatever state-machine based parser you come up with from scratch in PHP. Matching state-machine behavior to a formal grammar is much easier than matching it to intuition. Second, once you've debugged it will allow you to output "known-good" parse trees from the ANTLR debuggers, and compare these against the ones you generate with your PHP based parser, to give you an additional layer of debugging and test suites.
In this post, I will try to explain a bit more about ICE. I made a connection with Axe in my first post, but the only common is, that they are both parsing TI-BASIC. Axe is a totally different language, with other possibilities, while ICE just parse 'normal' BASIC. My hope is, to make ICE such, that it can compile EVERY normal BASIC program, like the OS do. The only difference is, that ICE will parse it BEFORE running, and the OS during running. An example:
We have this kind of code:

Code:
1->L1(3
What Axe Parser needs, is something like this:
Code:
1->{L1+3}
but the OS can't run such piece of code. This is how ICE works:

Code:
// express the index, -> 3
   ld hl, _base_of_L1
   add 3
   ld (hl), 1
In that way, the OS can still run it, and ICE too.

In other words, ICE is not a totally different language, it's only a small threshold to ASM.
I hope you now fully understand my goal Smile
Wonderful project! Has any demo come out of this, however limited?

I'm fully supportive of any on-calc language that compiles to Asm (even if it is just BASIC). I think it might just be the thing that gets me into CE development!
I have been in the same boat before, thinking if i should create a shell, a MC port, or something else. What i came to is this: make what you want Wink Dont listen to people , just do it, and have fun doing it. You're not programming because you are being paid to, you are programming because it's your hobby. Just have fun Smile
I support the idea of compiling TI-BASIC into eZ80 machine code, but creating a different BASIC like language might be a misdirection of effort. The lack of certain features in TI-BASIC would not be compensated for by creating another language devoid of the vast number of OS commands. I feel like C covers the area between TI-BASIC and eZ80 ASM well as a low-level compiled language.
jonbush wrote:
I support the idea of compiling TI-BASIC into eZ80 machine code, but creating a different BASIC like language might be a misdirection of effort. The lack of certain features in TI-BASIC would not be compensated for by creating another language devoid of the vast number of OS commands. I feel like C covers the area between TI-BASIC and eZ80 ASM well as a low-level compiled language.
Not necessarily. There are many people who found C so difficult compared to TI-BASIC that they are waiting until Axe or xLIBCE comes out before starting 84+CE development.

C has been available for ages on the 83+/84+ series, yet almost no one used it. Then once Axe came out, Axe programmers arrived in droves. If C was as easy as Axe as people claimed, then we would have gotten Reuben Quest and the Reign of Legends in C for both Z80 and 68K long ago.

A new interpreted or compiled language that has a syntax similar to Axe would bridge the gap even further. By the way, on the 83+/84+, there is another language that is actually interpreted and runs pretty fast compared to TI-BASIC, although slower than Axe: It's called Grammer, by Xeda112358. The main downside of an interpreted language, however, is that it requires the game player to carry an extra interpreter software on his calculator in order to run games made with it.

So I think a new language that is intended to be as easy (or close) as TI-BASIC, but faster, is welcome. But on Cemetech, people have the narrow-minded mentality that C bridges the gap between BASIC and ASM, so perhaps such language would have a better reception and popularity on Omnimaga (which is the home of Axe, after all) and CodeWalrus. However, it would require to be programmable in Token, SourceCoder 3, in the on-calc BASIC editor and TI-Connect CE.
The narrow-minded mentality stems from the fact that the 83+/84+ is illy suited for C, so that argument is invalid. The CE is specifically targeted for C, with even a non-community compiler. That's a really big difference. C is orders of magnitude easier to read and debug than Axe as well, and has many, many more features and options. Back on topic, I would say this would be a really neat project; a lot of work; and I wish you the best of luck PT_ Smile
DJ_O wrote:
C has been available for ages on the 83+/84+ series, yet almost no one used it. Then once Axe came out, Axe programmers arrived in droves. If C was as easy as Axe as people claimed, then we would have gotten Reuben Quest and the Reign of Legends in C for both Z80 and 68K long ago.

C on the z80 wasn't really usable. And there was no toolchain/SDK/tools/whatever that now exist for the CE (or at least as developed)
C may 'bridge the gap', but it has one fatal flaw- there are no on calc C compilers. One reason i never released any 100% asm programs on the TI-8x+ is becouse there are no good asm IDEs- simply because the screen is too small to be able to understand anything >_>
I hope that a compiled language with a Axe-like syntax be made forthe CE
MateoConLechuga wrote:
The narrow-minded mentality stems from the fact that the 83+/84+ is illy suited for C, so that argument is invalid. The CE is specifically targeted for C, with even a non-community compiler. That's a really big difference. C is orders of magnitude easier to read and debug than Axe as well, and has many, many more features and options. Back on topic, I would say this would be a really neat project; a lot of work; and I wish you the best of luck PT_ Smile
I actually found C much more difficult to learn than Axe, at least until I reached the more advanced Axe commands that were implemented later. It only took me 5 minutes to learn how to do grayscale sprites in Axe, and that was before Axe even supported grayscale at all. In C, well... I gave up before even being able to draw any graphics, despite multiple learning attempts on Technoplaza when I tried to get into TI-89 programming.

It's not a fact, it depends of people's opinion and personality. There are people who find Axe more difficult than C and people who find C more difficult than Axe. And the narrow-minded mentality I was talking about is people who would rather prefer to see the second group of people to remain locked out from CE programming rather than seeing a new language like Axe or ICE. C fanboyism isn't a good way to make the TI community grow, just like how ASM fanboyism wasn't over a decade ago.
I've changed my primary goal a bit, which was to make it fully compatible with TI-BASIC. Now I see that that is impossible, a small example would be getKey, which returns different values as _GetCSC, and also floating numbers. That is why I go to make *another* language. I'm keeping most of the BASIC compatibility, such as Ans, and also use some other functions which are not possible with BASIC, such as saving data in programs or appvars. That is also why I'm going to work with integers, and not floating numbers, because they are slooww.

Today, I made a nice begin with the main algorithm Smile
PT_ wrote:
I've changed my primary goal a bit, which was to make it fully compatible with TI-BASIC. Now I see that that is impossible, a small example would be getKey, which returns different values as _GetCSC, and also floating numbers. That is why I go to make *another* language. I'm keeping most of the BASIC compatibility, such as Ans, and also use some other functions which are not possible with BASIC, such as saving data in programs or appvars. That is also why I'm going to work with integers, and not floating numbers, because they are slooww.

Today, I made a nice begin with the main algorithm Smile


Sounds like a good idea to deviate from BASIC, as you can now feel free to add features Smile I can't wait to see the progress you make on this.
PT_ wrote:
I've changed my primary goal a bit, which was to make it fully compatible with TI-BASIC. Now I see that that is impossible, a small example would be getKey, which returns different values as _GetCSC, and also floating numbers. That is why I go to make *another* language. I'm keeping most of the BASIC compatibility, such as Ans, and also use some other functions which are not possible with BASIC, such as saving data in programs or appvars. That is also why I'm going to work with integers, and not floating numbers, because they are slooww.

Today, I made a nice begin with the main algorithm Smile

I think you mean nearly impossible, since there exists a formula to go from the _GetCSC codes to the getKey codes although I don't know what it is Razz Either way I think you are making a good choice by moving a little away from basic, besides, for programming, people can usually get away with just integers Smile Also, this will give you the opportunity to slip in some useful commands. As a basic programmer who doesn't really have the time or the keenness to learn ASM, this is sure to be a wonderful tool Very Happy by the way, I thought of this a while ago Razz I wish you the best of luck with this project and I hope to see this grow into a nice useful tool!
I haven't yet finished it, but here you can find my algorithm for parsing a mathematical string. I've fully implemented the Shunting-Yard-Algorithm, and now working on evaluating that. I hope to make good progress these weeks! Good Idea
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 23
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement