??? 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:
ld a, (address_of_A)
ld l, a
ld a, (address_of_B)
ld h, a
mlt hl
ld a, l

add a, 3
. I did it with leaving a special value at the stack, after adding/multiplying/whatever'ing two values. For more technical details, pm me Very Happy

As always, I hope to make good progress, but unfortunately, these two weeks I have my final exams, so no free time for programming Sad
(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. Smile

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 Razz).

Anyway, this looks fantastic! Be sure to keep the OP up to date with your progress. Smile
Thanks Smile
Hactar wrote:
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?

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 Smile
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:
{i}PROGNAME

{i}PROGNAME DESCRIPTION OF MY PROGRAM
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:
{i}PROGNAME

{i}PROGNAME
{i}DESCRIPTION OF MY PROGRAM
In fact, you might want to consider a third option as well:
Code:
{i}PROGNAME
{i}DESCRIPTION OF MY PROGRAM
{i}DCE ICON
I dont think the source code should have an icon. The compiled executable, yes, but the source code, no.
c4ooo wrote:
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.
Ivoah wrote:
c4ooo wrote:
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. Wink
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:
  ld hl, ICEname
  call _Mov9ToOP1
  call _ChkFindSym
  ex de, hl
  ; skip header
  inc hl
  inc hl
  push hl    ; save for later
    ld hl, varname
    call _Mov9ToOP1
  pop hl
  ld (callAdress), hl
callAdress = $+1
  call $000000
  ; continue

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:
  jr noAPI
  jr APIContinue
noAPI:
  header....
APIContinue:
  call _ChkFindSym
etc
Soooo, I found some bugs with the logic operators Sad
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 Very Happy
Thanks in advance! Smile


Code:
= (equal)
  A=B: ld a, (address_A) \ ld hl, address_B \ sub a, (hl) \ sub a, 1 \ ccf \ sbc a, a \ inc a            64 cc
  A=*: ld a, (address_A) \ sub a, * \ sub a, 1 \ ccf \ sbc a, a \ inc a                              48 cc
  *=A: ld a, (address_A) \ sub a, * \ sub a, 1 \ ccf \ sbc a, a \ inc a                              48 cc
 
≠ (not equal)
  A≠B: ld a, (address_A) \ ld hl, address_B \ sub a, (hl) \ sub a, 1 \ sbc a, a \ inc a                  60 cc
  A≠*: ld a, (address_A) \ sub a, * \ sub a, 1 \ sbc a, a \ inc a                                 44 cc
  *≠A: ld a, (address_A) \ sub a, * \ sub a, 1 \ sbc a, a \ inc a                                 44 cc
 
≥ (greater than/equal)
  A≥B: ld a, (address_A) \ ld hl, address_B \ sub a, (hl) \ sbc a, a \ inc a                        52 cc
  A≥*: ld a, (address_A) \ sub a, * \ sbc a, a \ inc a                                          36 cc
  *≥A: ld a, (address_A) \ scf \ sbc a, * \ sbc a, a \ and a, 1                                    44 cc
 
≤ (lower than/equal)
  A≤B: ld a, (address_A) \ ld hl, address_B \ scf \ sbc a, (hl) \ sbc a, a \ and a, 1                  60 cc
  A≤*: ld a, (address_A) \ scf \ sbc a, * \ sbc a, a \ and a, 1                                    44 cc
  *≤A: ld a, (address_A) \ sub a, * \ sbc a, a \ inc a                                          36 cc
 
> (greater than)
  A>B: ld a, (address_A) \ ld hl, address_B \ scf \ sbc a, (hl) \ sbc a, a \ inc a                     56 cc
  A>*: ld a, (address_A) \ scf \ sbc a, * \ sbc a, a \ inc a                                    40 cc
  *>A: ld a, (address_A) \ sub a, * \ sbc a, a \ and 1                                          40 cc
 
< (lower than)
  A<B: ld a, (address_A) \ ld hl, address_B \ sub a, (hl) \ sbc a, a \ and a, 1                        56 cc
  A<*: ld a, (address_A) \ sub a, * \ sbc a, a \ and a, 1                                       40 cc
  *<A: ld a, (address_A) \ scf \ sbc a, * \ sbc a, a \ inc a                                    40 cc


EDIT: this is for unsigned numbers, and register A should contain 1 if true, and 0 otherwise Wink
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.
Hactar wrote:
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.)

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.

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

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.
PT_ wrote:

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

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:
PT_ wrote:

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.

PT_ wrote:

ICE programs won't run with the normal BASIC compiler

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.
oldmud0 wrote:
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! Smile
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:
ld a, ($D05301)    ; B
add a, a
add a, a
push af
   ld a, 1
   ld hl, $D05302  ; C
   sub a, (hl)
pop hl
ld l, 1
mlt hl
call _DivHLByA
ld a, l
ld hl, $D05300     ; A
add a, (hl)
add a, 3
ret
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 Very Happy
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 Smile I succesfully compiled a normal program, without any errors Very Happy

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 Very Happy

EDIT:

PT_ wrote:
I DID IT!!!!!!!!!

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

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?
  
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
» Goto page Previous  1, 2, 3, 4 ... 31, 32, 33  Next
» View previous topic :: View next topic  
Page 3 of 33
» All times are UTC - 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