Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: Quigibo on October 29, 2010, 04:57:51 am
-
I should probably have mentioned this a while ago, but as most of you can probably tell, I don't really have the type of free time that I used to have. The progress on Axe Parser has therefore been very slow due to the huge amount of work and projects I have to do for school. I'm usually up until after 2 am most nights just to finish all my assignments and prepare for midterms. I really really want to work more on Axe but I just don't see myself having time in the next few weeks. So just to let everyone know, the next time you will see an update will most likely be around thanksgiving weekend because I will finally have some free time then. After that, I will probably release 1.0.0 during the winter break, hopefully before the new year. (I can't believe its been almost a year since I started!)
So don't think I'm ignoring suggestions or bug concerns, I am still monitoring those frequently. I just simply won't be able to add those features for a while so even if they were mentioned a long time ago, I'm keeping a list of all the things I need to change. After 1.0.0 and all the axiom support is finalized, I am hoping that new commands requested will finally be simple enough for asm programmers to create the libraries themselves so you won't have to wait for these huge delays between updates to get new features.
Since this thread is about progress, I should probably mention what I plan on doing next. If I decide to go ahead with "Axe 2.0" I am thinking it will be a computer compiler rather than an on-calc compiler. It would be a variation of the language with much more traditional C-style syntax, but similar enough so that code written in Axe 1.0 can be directly converted into 2.0 with a built-in converter. I feel that large programs will be so much easier to make on a computer than on the calculator itself and since the compiler doesn't have the limits of size and speed that the calculator has. Therefore, I can make many many more optimizations, friendlier editing, unlimited sized apps, no risk of memory loss, etc.
If I decide not to do that, then I will likely be working on either a game or some computer based software or maybe some secret project.
-
thanks for the update
-
Best of luck on midterms.
As for your ideas on Axe 2.0, I'm cool with that so long as you don't completely stop development on an on-calc compiler. That's the main reason I use Axe.
Get some sleep!
-
Just wondering, how much control would the new axiom system have? Would it be able to do things like not just add token-based commands, but directly add modifications to the parsing process?
-
an computer compiler sound cool, but the oncalc compiler is pretty handy too, so it would be nice if you dont stop with that after v1.0.0
-
Sounds good. Computer compiler sounds much easier to use (but not as portable). I know what you mean about not having any time outside of school, though.
-
Will the computer version be written in C,C++,Java, or something else? If it is C++ or Java, I would love to help. I am very accomplished in both of those languages, and have seemingly a lot more free time than you, Quigibo. If it is not in either of those languages, I would still be willing to help, I would just have to learn the language first. However, that probably wouldn't take as much time as it sounds (I'm a VERY fast learner). I would suggest using Java, as it is cross-platform, and so could be used by anyone who uses the Axe Parser. If you want to contact me, please email me.
-
Would the computer version be able to output z80 assembly code instead of just machine code? That would be pretty cool.
-
Actually, I had thought of that as well. Using a combination of the routines source for Axe, and TASM's z80 table file, I think code could be compiled to assembly, hex, and machine code.
-
Would the computer version be able to output z80 assembly code instead of just machine code? That would be pretty cool.
^ This :D
Or you could link it to a disassembler.
Anyway, sounds great! Can't wait to see what the final version of Axe'll look like. Good luck on midterms!
-
Interesting, I wish you good luck with school!
As for the on-computer compiler, it might be nice indeed. That said, as I like to code on-calc, I think I will probably stick to Axe 1.0.0, though. As someone mentionned, its on-calc-ness is the main reason why I use Axe.
If a computer compiler is done, it would be cool if somebody could port Axe to 68K and TI-Nspire calculators as well.
-
Just thinking "out-loud" here but, couldn't you just make a bunch of different files with defines (TASM-style maybe) that would then correspond to actual asm code for each individual calc. Kind of like how they made Java cross-platform. Or also, if the main instruction set for the calcs is the same, you could have the actual code, then have specific calls to parts that aren't the same for all calcs. These specific calls would have a define file of their own, and so could then define ACTUAL code for each different calc (I was thinkin of b_calls here). This would provide the same level of abstraction while still being cross-calc compatible.
-
I would really find it sad when you won't continue on-calc programming support for Axe 2.0, but it would be very nice to be able to program in Axe ON-PC as well. Just like the others said before me. ;)
-
Just thinking "out-loud" here but, couldn't you just make a bunch of different files with defines (TASM-style maybe) that would then correspond to actual asm code for each individual calc. Kind of like how they made Java cross-platform. Or also, if the main instruction set for the calcs is the same, you could have the actual code, then have specific calls to parts that aren't the same for all calcs. These specific calls would have a define file of their own, and so could then define ACTUAL code for each different calc (I was thinkin of b_calls here). This would provide the same level of abstraction while still being cross-calc compatible.
Yeah I think that's what TIGCC for 68K calcs did, in order to allow simultaneous compiling for the 89, 89T, 92+ and Voyage 200. It would be nice to have something like that in Axe. Maybe Axe 2.0 could become the new Multi-Platform Language for Calculators? (MLC was an old language project in 2005 designed to run on Casio, TI-z80 and 68K calcs. There was even an HP port planned. MLC was an interpreter, though, not a compiler.)
-
Again I say, it wouldn't be to hard to do. Unless there were any changes to the parser itself, the program would only have to be written once. All the data and stuff would be kept externally so the program itself wouldn't have to be modified. Also, the program could be written in Java and compiled to native for the different platforms (yes this is possible, at least for Windows and Linux).
-
Good luck for school and for axe upadting too.
I contacted you with a bug by the way, I am of the opinion that if all of us contribute you can launch 1.0.0 before new year :)
-
You seem to think a lot of stuff is so easy to achieve. Do you think you could help a little bit on such project, in that case? ;)
-
I'll help. Definitely. Just tell me what to do!
-
Thanksgiving weekend is coming close, can't wait ;D
@Quigibo: What features do you plan on adding for the next version?
-
Coding marathon starting now!
I'll be coding every day for one week so that I can release Axe 0.4.6 by next Sunday. Every day, I will post the new features I have added so far and the ones I am planning to add the following day.
Did Today:
Fixed Comment Bug
Added New Axiom Tokens
OnKey support for getKey(41)
Doing Tomorrow:
Fix Elseif bug
Add new auto-optimizations
Static data storable to variable pointer.
Backup only after finishing compile with no errors.
-
Cool to hear! Good luck Quigibo!
-
Cool! Thanks for working on this!
-
Nice! I can't wait for the next release :D Good luck on the coding spree!
-
Speaking of auto-optimizations, what happened to the signed division auto-optimizations? They seem to have disappeared.
-
Coding marathon starting now!
I'll be coding every day for one week so that I can release Axe 0.4.6 by next Sunday. Every day, I will post the new features I have added so far and the ones I am planning to add the following day.
Did Today:
Fixed Comment Bug
Added New Axiom Tokens
OnKey support for getKey(41)
Doing Tomorrow:
Fix Elseif bug
Add new auto-optimizations
Static data storable to variable pointer.
Backup only after finishing compile with no errors.
/me LIKE WANT NEED
Seriously, that's pretty awesome. ON key support will be really useful for me ;D
-
Sounds awesome! I can't wait for Axioms to be re-integrated.
-
Awesome! I can't wait. ;D
-
Did Today:
Fixed Elseif bug
Added new auto-optimizations
Static data storable to variable pointer
Backup only after finishing compile with no errors
Compiling to apps always attempts a defragmentation
App signature improved and resignable on-calc with external program
Doing Tomorrow:
Get started on absolute jumping/calling from Axioms/Internal commands
Fix program menu bug
Pressing alpha-character jumps to program in menu (some backup control keys will have to change)
Fix sector boundary reading bug when reading from archive.
Things are coming along great! :)
-
Huzzah!
i am particularly excited for axioms. some people might be a little disappointed withBackup only after finishing compile with no errors
, because it before it could be exploited to make easy backups for any basic Prog... :P
-
can't you just press the B button to make an auto backup?
-
cool :D
Glad to see this is progressing again. :D
-
can't you just press the B button to make an auto backup?
Not anymore. The B button now is going to be used to scroll in the program list to the first program starting with a 'B'. The new button will be 'Alpha' most likely. And yes, you can still use that to exploit BASIC programs for backup :)
-
awesome, thanks!
-
Oh yes thats right ;D Well glad to know it will till work :)
-
For BASIC backups do you guys just have to add a dot and letter at the beginning then backup through Axe?
-
Yep ^^ and it works wonderfully :)
-
Ah cool :D
I personally just archived my programs or rcl'ed code in another then archived the copy, but this takes a while...
-
If i want to duplicate a program i just group it, and then ungroup it and rename it (only works if its less than half the suze of ram tho)
-
Yeah, true, and it sometimes ERR:VERSIONs...
-
Quigibo, do you think you're going to change the location of A - Z, theta, and the random number seed in this version? I hope you do, as if you do we get an extra buffer and can use Calc2Net. :)
I'm glad things are going along smoothly. ;D
-
can't you just press the B button to make an auto backup?
Not anymore. The B button now is going to be used to scroll in the program list to the first program starting with a 'B'. The new button will be 'Alpha' most likely. And yes, you can still use that to exploit BASIC programs for backup :)
Nice, I liked that feature ;D
-
Can't CALCnet be used on another buffer like an arbitrary one or even the back buffer, or does it only use L1?
-
Can't CALCnet be used on another buffer like an arbitrary one or even the back buffer, or does it only use L1?
I believe it needs the start of L1.
-
calcnet support in axe would be pretty sweet :)
-
I think first there should be perfect linking between two calcs.
The longer the cord the worse it is...
-
Okay, I think I can do it: Select(CONST) will be able to set where you want the variables in an Axe program from that point on in the program. You can use it multiple times in the same program to swap back and forth between different buffers to effectively increase the number of variables available to the programmer. The command is a compiler instruction and thus takes no memory in the executable so there is never a penalty to using it. Also, the variables will from now on be at the end of L1 by default instead of the beginning. That way, if you do move the variables, you will be able to use the full 768 byte L1 buffer by simply using L1 instead of having to use L1-56. Future optimizations might also be possible in the future if the variables are kept within that range.
EDIT: 1337th post! ;D
-
Okay, I think I can do it: Select(CONST) will be able to set where you want the variables in an Axe program from that point on in the program. You can use it multiple times in the same program to swap back and forth between different buffers to effectively increase the number of variables available to the programmer. The command is a compiler instruction and thus takes no memory in the executable so there is never a penalty to using it. Also, the variables will from now on be at the end of L1 by default instead of the beginning. That way, if you do move the variables, you will be able to use the full 768 byte L1 buffer by simply using L1 instead of having to use L1-56. Future optimizations might also be possible in the future if the variables are kept within that range.
YES! That is awesome! And I assume we can do something like Select(GDB0) as well? This is really convenient for me :D
-
Sweet! That is amazingly awesome! I can't wait to use it! ;D
-
Okay, I think I can do it: Select(CONST) will be able to set where you want the variables in an Axe program from that point on in the program. You can use it multiple times in the same program to swap back and forth between different buffers to effectively increase the number of variables available to the programmer. The command is a compiler instruction and thus takes no memory in the executable so there is never a penalty to using it. Also, the variables will from now on be at the end of L1 by default instead of the beginning. That way, if you do move the variables, you will be able to use the full 768 byte L1 buffer by simply using L1 instead of having to use L1-56. Future optimizations might also be possible in the future if the variables are kept within that range.
EDIT: 1337th post! ;D
Nice! Are you going to add a constant that refers to the default location of the variables? I know they aren't going to be L1-56 any more, might they be L1+712 or something?
-
Okay, I think I can do it: Select(CONST) will be able to set where you want the variables in an Axe program from that point on in the program. You can use it multiple times in the same program to swap back and forth between different buffers to effectively increase the number of variables available to the programmer. The command is a compiler instruction and thus takes no memory in the executable so there is never a penalty to using it. Also, the variables will from now on be at the end of L1 by default instead of the beginning. That way, if you do move the variables, you will be able to use the full 768 byte L1 buffer by simply using L1 instead of having to use L1-56. Future optimizations might also be possible in the future if the variables are kept within that range.
YES! That is awesome! And I assume we can do something like Select(GDB0) as well? This is really convenient for me :D
Yes, anything that can be evaluated as a constant (something that was defined already in the program) can be used. Also things like L2, or1 or E8000 can also be acceptable. Just be VERY VERY careful. You need to make sure you actually have 56 bytes to work with and you need to be absolutely sure you aren't accidentally sharing the same variable space with some other memory that needs it. Also, using dereferencing like oA will automatically adapt to the current space you are working with.
EDIT: Good idea calc84maniac! I might do that.
-
Hmmmmm so then since these are compiler commands, certain things will not work, am i correct? Like:
If A=3
Select(L2)
Else
Select(L3)
End
Would not work correct?
-
Yeah, that would not work. It would select L2 and then L3 so by the end of that command, it would be at L3.
I might tack on a hash to the front of the token to indicate it is a compiler instruction rather than a language one to make it less confusing. When I get to adding custom icons, I can also do it the same way:
#Select()
#Icon[]
-
Yeah, that would not work. It would select L2 and then L3 so by the end of that command, it would be at L3.
I might tack on a hash to the front of the token to indicate it is a compiler instruction rather than a language one to make it less confusing. When I get to adding custom icons, I can also do it the same way:
#Select()
#Icon[]
That's a good idea. #include for prgm, maybe? Just an idea, doesn't really matter :D
By the way, will the default A-Z and θ locations be moved to the end of L2?
And nice 1337 ;D
-
By the way, I love Quigibo's signature:
"Axe Parser 1.0.0
[=====-----] 50%" :D 50% means half is done (you may say half to do, but I'm optimist!)
-
Yeah true. I hope later he'll be able to find more time to work on it regularly again. :P (after the next beta arrives)
-
Awesome! I can't wait for Select()! ;D