This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Quigibo
Pages: 1 ... 47 48 [49] 50 51 ... 135
721
« on: October 31, 2010, 09:00:59 pm »
You can always use Mimas... its an on-calc compiler for z80 assembly so you wouldn't need the computer at all. I used to program in hex and I can tell you from experience, its way too much of a hassle, even for small programs, especially due to needing to update all the labels every time you change your code. Please use an assembler if you expect anyone to be able to help you with your problem because no one is going to want to go through this line by line to try to translate what you were trying to do.
722
« on: October 31, 2010, 05:55:17 pm »
You actually can have multi-channeled sound right now using the "Port" command to get similar quality to quadplayer. There is no way you'd be able to have much of a game going on in the background though, but if you're just doing this for the audio itself, it sure is possible, just a little tricky.
723
« on: October 30, 2010, 03:24:35 pm »
Those are the sizes of the subroutines, not the calling routines. The first time you use Pt-On for instance, it creates the subroutine in the data section. Then, it calls to that routine. Each call after that no longer has to recreate that routine anymore and just links to the one that already exists. The only time you would want to put an Axe call in a subroutine is if you're always using a specific combination of arguments over and over again in the code.
If you want to know the calling overhead, compile "Pt-On(1,2,3):Pt-On(4,5,6)" and subtract that size with "Pt-On(1,2,3)" and that's your calling overhead.
724
« 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.
725
« on: October 29, 2010, 04:32:11 am »
My guess is that it was probably another program that corrupted his compiled program or some other corrupted ram before running the program that caused one of the OS calls to freeze. There definitely should not be undocumented instructions in any of the compiled programs.
726
« on: October 29, 2010, 12:35:16 am »
I don't like using the alphabetical sorting BCALLs. I used to use them in early versions of Axe and it made the list populate extremely slowly when there are a lot of programs on the calculator becasue it has to sort the entire VAT up to the n-th item for each call you make. What Axe does now is sort the entire VAT only once when the program starts and then pass through the list sequentially. The actual code to move to the next entry is about the same size as the BCALL anyway so I might as well just go with a faster solution.
After thinking about it for a while, I realized the entire scanner could be a single routine:
Vat(P)
Takes one argument:
If the argument is zero, it returns a pointer to the first entry in the vat.
If the argument is a pointer, returns the next vat entry after the pointer.
If there are no more entries after the pointer, returns 0 (end of VAT).
Not sure if a command like this would actually be that useful though, its still confusing to read the entry since they have backwards names and a specific order of the byte fields. I'd rather not have to add 5 other commands to read all the fields either, it seems more like something a library routine should do instead of a built-in feature.
727
« on: October 27, 2010, 04:50:25 pm »
I wonder if you can use a label as a pointer, like by doing lbl123+64
You would never reliably be able to do this because future optimizations would mean that the spacing between some labels would change between every version of the parser. This would only work if the entire routine were written with an Asm() command so you would know the length of the subroutine ahead of time. Unfortunately there is no way around the 150 symbol limit to labels, but there are some things you can do to use less labels in general. First of all, if you aren't calling it as a subroutine, you probably don't need it as a label. You can instead use a combination of if's and while's to handle those situations properly (remember, most modern programming languages don't even have a goto command). Another thing, if you have labels that are never used, comment them out becasue they still take up space on the symbol table even if they are never called.
728
« on: October 26, 2010, 03:24:45 pm »
JustCause doesn't give up.
He doesn't let you down either. But does he run around and desert you?
729
« on: October 25, 2010, 10:39:02 pm »
Oh you're right, it is in 0.4.5 I was using an older version. It has to do with the disabled axioms which are supposed to be checked once the parser doesn't recognize a token but I commented that all out and put a jump to the error handler instead. Unfortunately I accidentally made it a conditional jump instead of a normal jump and so it will sometimes not go to the error like it should and just continues on as if it were a comment.
730
« on: October 25, 2010, 09:36:14 pm »
Runer, I can't replicate that effect, it just throws a BAD SYMBOL at the 'o' for me as I would expect. What version are you using?
731
« on: October 25, 2010, 09:26:17 pm »
As for the subprograms, they are not actual "sub" programs put part of the original code itself. Thus you can make block abstractions within your code: .MainProg
prgmFOREACH
.Do Stuff to element
prgmENDEACH
..ForEach
.Initialization
For(A,0,N)
.Setup
..EndFor
.Clean Up
End
.Destructor
I could check to make sure that the block level count before and after reading a subprogram is the same but then you wouldn't be able to use these abstractions. Backing up subprograms would be a little awkward to compile. It would first backup the main program then start compiling and whenever it sees a subprogram, pause compiling to back it up and then resume. The best solution is to just keep your subprograms in archive and only have the programs you're actually editing in the ram. But I will see if it is possible to have this as an option. I can't scan the program looking for subprograms ahead of time because it would have to ignore comments, quotes, characters, absorbed data, etc. which are taken care of during the actual compile. Also, I've been thinking... to avoid the corrupted ram issue, maybe I should have the main program get backed up at the end instead of the beginning of the compile. That way in case a bad program corrupts your program, it probably won't be able to finish the compile successfully and therefore will not replace the last backup. Also, getting any other syntax error will mean you have to go back and fix it so it shouldn't need to waste time archiving. In other words, if it can't compile, the problem must be fixed before replacing the last working backup. The only danger is in case Axe crashes the program in ram would be lost, but I don't think I have those problems anymore. Also you can't use that trick to backup BASIC programs anymore (but you can write a program to do that in Axe  )
732
« on: October 22, 2010, 07:03:55 pm »
Try removing and then reinserting the backup battery. If that still doesn't work try to do a garbage collect or defragment because those rebuild the app menu I think. I had the same problem when I was figuring out how to add apps to the menu after creating them in Axe. I think Axe uses the rebuild code too so if you try to compile any program as an app in Axe then it should regenerate the table for you. This is all assuming the problem is what I think it is... but definitely back up stuff first.
733
« on: October 21, 2010, 11:50:48 pm »
Sorry, that was a typo -_-
734
« on: October 21, 2010, 11:49:17 pm »
Simply replace "Str9" with "L1" or some other free ram. Then you can call "Disp L1" later. Don't forget to add the null character at the end of the string.
735
« on: October 21, 2010, 11:42:03 pm »
In response to 6, no apps don't take up space in RAM. But the side effect to this is that you can't use self modifying code with your program data, you would have to copy it to free ram to make modifications.
Bcalls are ALWAYS slower, but they're much smaller, so it depends on what kind of trade-off you need with size vs speed. For something like getting the free memory, I'm guessing you wouldn't be calling it 1000 times a second so the bcall is probably fine. Conversely, division for example has a smaller bcall, but I don't use it because the performance is much more important for a function like that.
Pages: 1 ... 47 48 [49] 50 51 ... 135
|
Show Posts