0 Members and 4 Guests are viewing this topic.
Disp "ICE","ICE"
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
F/2+3->A
F 2 / 3 + A ->
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
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 expressioncompiler, 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
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
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)
push hl \ push hl \ push hl \ push hl \ push hl \ push hl \ push hl \ push hl \ push hl \ push hl ld hl, 3ld bc, 3call _imulipop bc \ pop bc \ pop bc \ pop bc \ pop bc \ pop bc \ pop bc \ pop bc \ pop bc \ pop bcld bc, 3add hl, bc
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).
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 becomeCode: [Select]push hl \ push hl \ push hl \ push hl \ push hl \ push hl \ push hl \ push hl \ push hl \ push hl ld hl, 3ld bc, 3call _imulipop bc \ pop bc \ pop bc \ pop bc \ pop bc \ pop bc \ pop bc \ pop bc \ pop bc \ pop bcld bc, 3add hl, bc?
ld hl, 3push hlld hl, 4ld bc, 5call _imulipop bcadd hl, bc
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]ld hl, 3push hlld hl, 4ld bc, 5call _imulipop bcadd hl, bc
ld h, 4ld l, 5mlt hlld a, ladd a, 3
Quote from: Cumred_Snektron on March 25, 2016, 01:50:49 pmInteresting 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 expressioncompiler, 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!
WalrusIRC
