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 ... 52 53 [54] 55 56 ... 135
796
« on: September 27, 2010, 11:48:54 pm »
Oh! I forgot to mention something really important about recursive subroutines!
Even thought they take up more space in the program than the regular subroutines, there is a new way to optimize them. The "last expression" for each argument is the original argument. What I mean, is that instead of this:
sub(FACr,r1-1)
You can actually write this:
sub(FACr,-1)
Because the r1 is implied. Same thing applies to r2, r3, etc in the rest of the arguments. For any actual recursion, its an extremely important optimization since generally you use the previous value in your expression for the next value passed.
797
« on: September 27, 2010, 11:41:10 pm »
I'm not saying its impossible, I just mean that it would be annoying to happen every time you compile a program. You definitely need to know when you're over the limit because that's a safety issue (potential crashes), but for smaller programs its not important since you cn check in the [2nd][Mem] menu anyway.
I like the idea of an option for it though. I could display other statistics too like the number Axe subroutines used, percent data, tip of the day, etc.
798
« on: September 27, 2010, 09:59:38 pm »
The main problem with that is the compiler doesn't know how big the output file is until it finishes compiling. It would have to pause when its done somehow to allow the user to see the number which I think would annoy a lot of people who want speedy fast compiling, especially for smaller programs.
799
« on: September 27, 2010, 09:53:11 pm »
Axe Parser
Delta 0.4.5
Wow, its been a while  New Features:- Direct Nibble manipulation!
- Subroutines can save and restore argument variables (for recursive uses).
- Most Axe variables can be dereferenced.
Changed:- Correct number of Ends after nested elseif statements
- White space in program is handled better when scrolling to an error.
- Axioms are temporarily disabled.
- Fixed Auto Power Down bug.
- getkey() routines alway delay long enough to register a key even in 15MHz.
- DispGraphrr can be used in an interrupt routine now.
- Optimized Copy() Fill() and Exch() commands.
800
« on: September 27, 2010, 09:12:12 pm »
I think I will give a warning message from now on when the size passes 8812 bytes.
801
« on: September 26, 2010, 10:05:06 pm »
I was actually just doing this recently for a Markov Chain in a research project. You can do this:
1: Sum up all the numbers
2: Choose a random number between 1 and the sum
3: Set an accumulate variable to zero
4: Scan the list from left to right adding each value to the accumulator
5: Once the accumulator is equal to or passes the random number, choose that element.
EDIT: Wow, I was ninja'd
802
« on: September 26, 2010, 09:56:04 pm »
The speed is negligible. If you checked for 80 key presses, it would be the same as an extra "Pause 1" which means each key would only add about 1/80th of a pause number. The main reason I've been avoiding it is because it makes the code larger and having separate routines makes it even worse. So at this point I think I'll just add an extra byte to give it a total of 20 clock cycles regardless of speed. This should settle the matter.
803
« on: September 26, 2010, 07:34:44 pm »
The "Pause" command is a a loop of "djnz $+0" commands which is equivalent to about 850 nop's per pause number.
The original getkey(#) command waited 8 clock cycles which I think is enough for 6MHz. getkey(0) was a separate routine which only waited 4 clock cycles. I have now merged the 2 into a single command that waits 13 clock cycles which might be enough for 15MHz. As a result, the getkey routine is a little larger, but each call to getkey(0) is 3 bytes less now, so the program size would actually go down if you were using it more than once.
804
« on: September 26, 2010, 07:18:43 pm »
I thought it would be last night but after more testing I realized I hadn't actually fixed the nested elseif bug properly for all cases and its taking me forever to fix it. Once I fix that, it will be ready.
805
« on: September 26, 2010, 03:02:56 pm »
By the way, adding a pause in a loop with a getkey doesn't actually do anything control-wise other than make the response time a little slower. The pause needs to be internal in the getkey routine itself (which I have fixed now).
806
« on: September 26, 2010, 12:25:19 am »
Size is definitely going to be larger for compiled Axe programs than pure ASM, but the speed will be about the same with an exception of highly math intensive programs like 3D graphics or particle systems in which case it would be a little bit slower.
I think the biggest disadvantage right now with Axe compared to assembly is not the size or speed of the program, but the difficulty of managing large projects. Since its typed onto the calculator screen from a calculator generally, its fast and convenient to make a small program, but once you have like 5 include files and 20KB of source code, it can get pretty annoying to work with your code. With assembly, you have an entire computer screen of code, its easy to type with the keyboard, you have no size considerations, no accidental loss of data, simultaneous editing, etc. But currently, there aren't many good computer editors right now for BASIC/Axe.
So if this is going to be a really really big project, you might want to learn assembly. But if you're new to assembly, you probably shouldn't work on such a big project as your first project anyway, and Axe will help transition from BASIC to assembly. This is just my preference though. Some people are able to manage and create incredibly huge games that basically take up the entire memory of the calculator <.<
807
« on: September 25, 2010, 02:53:54 pm »
It should work with sub(), but I'm not sure if it will work with the recursive sub(). By the way, is this the best way to do it to have a subroutine that is simply "jp (hl)" and then just call that subroutine whenever I want to "call hl"?
I haven't started adding this feature yet so I can't really give any screenshots or visualizations, but I will provide an example when its released. Its a fairly complicated and rarely used feature so don't worry too much about it.
808
« on: September 25, 2010, 02:41:28 pm »
It will be a set of extra parenthesis:
Goto A Jumps to label A
Goto (A) Jumps to the address that the Variable A holds
EDIT: @calc84
That's actually exactly what the multiplications do with multiples of 2 so left shifting is already optimized this way. Right shifting however I am not currently doing this becasue it takes 8 bytes whereas it only takes 6 to call the division with an argument. Do you thinking that I should optimize this for speed instead of size?
809
« on: September 25, 2010, 02:27:48 pm »
It might be ready tonight, because as another last minute decision, I decided to add support for expression valued label jumping! The main reason is I thought it would be cool to add function pointers (which point to routines instead of data) because then you can do A LOT of crazy stuff with that. For instance, lets say you write a subroutine that takes every element in a list and does an operation to it. You can call that with a subroutine that takes as arguments: a list and a function pointer. The routine then would call that function on each member of the list. Like a function that squares the number, doubles the number, adds 1 to the number, or something really complicated. Plus, a lot of asm programmers have been bugging me to add it for their other diabolical uses  . By the way, the new syntax for recursive subroutines is now this: sub(LBLr,1,2,3)Its becasue it makes it easier for the compiler to know what type of routine it is before evaluating the arguments. Surprisingly though, you rarely need it. Tail calls don't need them so you can actually write a lot of recursive subroutines already without this new feature. Like for instance, this: :.RECFACT
:
:.Find 6 factorial
:Disp sub(F,6)>Dec
:Return
:
:.FACTORIAL
:Lbl F
:!If r1
: 1
: Return
:End
:r1*sub(F,r1-1)
:Return
EDIT: @Nemo Yeah, *2 is shift left and /2 is shift right. They automatically optimize to the bit-shift instead of the multiplication.
810
« on: September 22, 2010, 07:00:16 pm »
The inc and dec instructions don't affect flags when used with 16-bit register pairs.
Pages: 1 ... 52 53 [54] 55 56 ... 135
|
Show Posts