ICE Compiler ti-84+ce

[MateoConLechuga]

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.

Ah, that totally makes sense I dislike that a lot too; I see what I can fix about it

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

Ah, yeah, that sounds rather difficult Pretty neat idea though, sounds like it would be quite nice

[PT_]

Today I've started creating an image, as for the homescreen of the ASM port, and as a logo for my documentation. This is the result:



Do you like it? Wanna change something?

[Unicorn]

That looks pretty nice!
Maybe get rid of the Options:  text? It seems a bit unnessicary

[Snektron]

That looks pretty awesome! Good job
Meanwhile i've also thought of more complexities: formula's like (a + b) / (c + d) aren't possible without a stack
(actually this one is, but formula's can always be expanded for more complexity )

[PT_]

That looks pretty awesome! Good job
Meanwhile i've also thought of more complexities: formula's like (a + b) / (c + d) aren't possible without a stack
(actually this one is, but formula's can always be expanded for more complexity )

Thanks
You have 2 ways to 'save' temporary data. One is indeed pushing the value on a stack, the other is just loading it in another register, which won't be used until that value will be used. Then you only need an algorithm to check whether you use that register. On another side, I've started porting this to ASM, and I have the numbers ready, and being busy with operators

[PT_]

While I had much free time today, I've implemented the operators in the Shunting Yard Algorithm in ASM, including their precedence. It now builds 2 stacks, one at (saveSScreen), the other at (saveSScreen+1000), one for the actual stack, and the first one for the output, which I need to read after that. Unfortunately, I have no screenshots of that
I hope to make good progress these weeks!

[Jkolade936]

Yay! Progress!
Keep up the good work! 

[xlibman]

Today I've started creating an image, as for the homescreen of the ASM port, and as a logo for my documentation. This is the result:



Do you like it? Wanna change something?

I like it, but I was shocked by a post on Cemetech when you said the image alone was 70 KB large. That's nearly half of the calculator RAM, so if program code has to be edited from RAM, then that leaves about 35 KB left for games >.<

That's unless you use compression or that the image is an april fools joke, though. You could perhaps reduce the quality and amount of colors and implement compression? This title screen looks nice, though. Also I'm glad to see new progress. On a side note, will this language compiler be in pure ASM or will it use both C and ASM?

[PT_]

Today I've started creating an image, as for the homescreen of the ASM port, and as a logo for my documentation. This is the result:



Do you like it? Wanna change something?

I like it, but I was shocked by a post on Cemetech when you said the image alone was 70 KB large. That's nearly half of the calculator RAM, so if program code has to be edited from RAM, then that leaves about 35 KB left for games >.<

That's unless you use compression or that the image is an april fools joke, though. You could perhaps reduce the quality and amount of colors and implement compression? This title screen looks nice, though. Also I'm glad to see new progress. On a side note, will this language compiler be in pure ASM or will it use both C and ASM?

Yep Maybe I could go in 4bpp, which takes 'only' 35Kb or RAM, or even in 2pp, which takes still 17Kb. (NO April fool!) The compiler will be in pure ASM.

[xlibman]

What about making the background 160*240 and stretching it horizontally? Or even 160*120. You don't need much details, since it's ICE content that matters.

[Snektron]

You could also make a special blue palette for it

[xlibman]

Yeah that could work. I heard that lower bit modes are palette-based, so quality would not suffer much. Or you could store the bg in archive and read it from there when the title screen is loaded. The compiler would not be in one single file, but I bet people wouldn't mind much.

[PT_]

I'm very happy to say that I got the Shunting Yard Algorithm ready, for parsing the input to RPN notation, which is much easier for compiling. It builds 2 stack, at saveSScreen and saveSScreen+1000, each entry of 2 bytes, one for the type, and the other one for the token itself (yet no 2-byte tokens). These commands are already included:

Code: [Select]

0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZtheta+-*/,()and also the functions, like sin(, cos( etc.
Again, I'm really sorry to don't have screenshots yet, tomorrow I hope to work on parsing RPN notation. Be patience!
In the meantime, has someone a good code in ASM to get all the programs or should I write it myself?

NOTE: ^ has in ICE left-associativity, if-you-know-what-that-means-but-no-one-cares

[xlibman]

Nice PT_. Just one thing, though: Does it mean we will not be able to program in algebraic mode? Also I am unsure if I understand what you mean by left-associativity. D:

[PT_]

Nice PT_. Just one thing, though: Does it mean we will not be able to program in algebraic mode? Also I am unsure if I understand what you mean by left-associativity. D:

No, you just program like you always did qua mathematical expressions, such as 5*(2+3)-3. ICE will convert it to RPN notation, because parsing RPN notation is much easier (search Google for Infix->postfix). For Left-associativity, I will give you an example. When you calculate 1*2*3, you calculate (1*2)*3. Officially spoken, when you calculate 2^3^4, you calculate 2^(3^4) which is 10^24, because the ^ has right-associativity. But in the program editor, if you type 2^3^4, the TIOS will calculate it as (2^3)^4 which is 4096. ICE will do the same, such that 2^3^4 = (2^3)^4.
Hope this helps!