Another big problem is fixed: custom tokens. Now it finally works fine!



The code is so complicated you don't want to see it
I had 2 possibilities: either locating the hooks at a fixed point in RAM, or create my own appvar, and insert them. I chose the last option, because compiled ICE programs can use all the RAM, and I suffer what will happen when one accidentally overwrites the hooks. So, each time I start ICE, it checks if it exists, remove it if necessary and create an appvar with the hooks in it. Then it archives it, so it's a bit harder to delete it, and if you delete it from the memory management, it still exists. The main problem is, that you now don't know what the starting memory of the hooks is, for relative jumps/whatever. So yeah, it seems I fixed it, and I'm pretty happy with it ^^

Now that I have fixed the main structure, is it pretty easy to add new tokens.

What about this?

Looks great. Maybe some more drawing options. Like the triangle, a polygon with each x and y value for each point. Great job though!

I think a great idea would be a command that gives the program the ability to use the whole screen. One thing that's nice about ASM is its not restricted to the graph screen. Great job on this, PT

Very good work sir. I hope to see progress on the custom tokens especially the Sprite token.

Sorry, no updates this week. I had the introduction week of the university, and another camp, so yeah, pretty busy. I do have some free days now though, so I hope to make progress

Sometimes I'm an idiot.

Since ICE will support 3-byte integers, and also 1-byte integers, I thought I had to check if (for example) the variable is a 3- or 1-byte integer, and if the last case, have another routine, much easier and faster. (I hope you understand me). Say, we store first 5 to variable A, and then call A+3. If I gonna use my method, it's super easy, just ld (ix+0), 5 \ ld a, (ix+0) \ add a, 5. Works fine until....

What if you have a variable as a 1-byte integer, and then store a 3-byte value to the variable within an If-statement? Then it's impossible to know whether to use 1- or 3-byte-routines. The only solution is to use ALWAYS 3-byte integers, but yeah, that's pretty slow. (there are some exceptions, like for A/5 I could use _DivHLByA instead of __idivu)

Despite I'm not happy with this, coding would be a lot easier.

I think it is worth it to use 3 byte integers all the time, remember regular ti-basic is incredibly slow and it supports a lot of things (I can't remember exactly how many but it uses a lot more than 3 bytes for a regular fpn), just compiling it is already a big step towards making it faster. I find it a little funny how "pretty slow" to you is a handful of clock cycles

It would be nice to have ICE access the buffer or vram, as Mateo does with the toolchain. It would make Basic programs faster with moving graphics.

There will be sure an option to read/write from/to any memory location, and thus from vRAM too.

Outside of that, a fresh OS, with ICE and Cesium installed, and if you then run ICE from Cesium, the calc crashes. I will try to fix it.

Anywhere you say? Hahaha... let's modify the OS to tailor our needs!

Let me quote Mateo on this subject...


But yeah uhhh modifying the OS, although it is very doable, is kind of sketchy on the legal side of things, which is why there is little to no discussion about it.

Well, I'm really busy with school, so not really enough time to finish the next version. Despite that kind of struggles, I implemented lists, and only 2 options: storing a fixed custom list to an OS list (fixed = only integers allowed, no variables or whatever) and also doing operations on a single list element, like 5+L1(A-3) works too.
My test code was this:
Code:
which is only 14 bytes. ICE turns this into:

Code:
which is, if I'm right, 32/37 bytes. A bit too much, but I'm still proud of it

Also, I'm still working on the auto-optimization, which is pretty hard.

-- calc84 pointed me to a bug, that the offset to a list element needs to be multiplied with 3. Should be easy to fix though.

That said, the whole code for one operator ( - ) is done, which means I can continue with the others. That should go a little bit faster though, because I have the structure done.

PT_: Is the assembly code faster in the above example?

Yes it definitely is The BASIC code takes (estimated) 0.1s, while that ASM code takes around the 100 cycles, which is 1/480000 s, so yes

So I finally had a free day, so I made a lot of changes:

• You can now (re)compile archived programs
  
• ICE now compiles the whole program, instead of only the first line
  
• Fixed main structure
  
• Fixed operators + and -, the other 12 need to be done soon
  
• Added the function not(
  
• Added the structure for my custom tokens, still need to start with
  
• My custom tokens are now replacements of statistics tokens, instead of accented letters. I did this because TI-Planet members told me at least French people use them more than normal.
  
• Removed the Inc( and Dec( token, because these are only useful for 1-byte variables.
  
• Added the tokens switch( and case: which could be very useful in programming
  
• Added some safety. If it encounters an error, it jumps to a function that display the error string, but then it may happen that the stack is messed up, so I stored the beginning stack pointer somewhere, and recall it before an error.
  

To-Do-List for the next release:

• Cesium icon/description
  
• Auto-optimization
  
• Finish operators (2/14 done). This gonna take time
  
• Add more functions, at least the custom ones
  
• When you have only once Input or rand, it would be faster and smaller to move that directly into the output program, instead of calling it, like this:
  
  Code:
  
  <code>
<input code>
<code>
ret
  instead of
  Code:
  
  <code>
call <input>
<code>
ret
<input code>
  
  
• Get right random routine. (Done)
  

Well, every week I'm pretty busy, so I guess not many time for programming sadly

Hmmm, very clever of you to use the accented letters as tokens to be replaced, they do not have a purpose (besides text, but even then, a lot of them are not used in either English or French, which I feel are the two languages most spoken by calculator enthusiasts)
I've got a question about the error checking: Is the error checking done in the compiling phase or is it done every time the program is run?
These are two completely different things, error checking during the compiling is wonderful, while during execution seems a little excessive, since it is assumed that the people using the program know how to use it...

Are the old statistics tokens replaced when you exit the program?

Hmm, maybe you should read my post correctly, I use now the statistics tokens

Yes, all the error checking + warnings are shown during compile-time. Better said, in the output program there is nowhere error checking

No, you can only reach the custom tokens when you are in the program editor, and clearly nobody uses the statistics tokens within a program.

Added rand - 400 bytes extra The rand routine itself is 28 bytes large, but sometimes the registers shouldn't be overwritten, so push/pop is needed.
I got it from https://www.omnimaga.org/asm-language/ez80-optimized-routines/