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 - Runer112
Pages: 1 ... 14 15 [16] 17 18 ... 153
226
« on: September 02, 2014, 06:55:10 pm »
Sorry for the lack of responding. I was both physically and somewhat mentally ill for a while, so I ceased basically all activities outside of eating, sleeping, and entertainment. Anyways...In response to changing the code origin, as you guys have correctly figured out, Axe does indeed calculate PC directly from the offset in the compiled program. Making this user-controllable would probably be tricky from an implementation standpoint. There's also the important goal that I'd like to see Axe become higher-level over time rather than lower-level, an adding manual code origin control is quite contrary to this. That's not to say this capability cannot be added, though. Since the theoretical Axe 2.0 looks a lot like C in my head, it should support functions. Both function and data definitions could support keywords or something similar that specify origin, which I believe would provide the functionality needed for most uses in a pseudo high-level fashion. Something else : as using the r modifier on a variable only use its first byte, we could be able to do For(VARr,MIN,MAX) (or designed another way, probably better : For(VAR,MIN,MAX)r). Maybe also do the same for big-endian, with rr.
I've imagined the code for a for loop with a one-byte variable in my head for a bit now and am of the opinion that the general result would probably be larger than a for loop using a two-byte variable. The problem is that Axe has to evaluate the minimum and maximums as two-byte values in HL because that's the only way it knows how to evaluate arbitrary expressions, so the potential savings of using a one-byte value and arithmetic are killed by the conversions between one- and two-byte values. (Side note: it may seem like the For(EXPR)r command has no reason to exist for similar reasons, but the difference is that once the two-byte value is converted to a one-byte value at the start, all following operations are one-byte only) If both the minimum and maximum were constants, then all the logic could certainly be coded in smaller one-byte operations. But in the case that the compiler is special-casing for loops with constant bounds anyways, there's little point for the alternate one-byte syntax because it could automatically check if both constants are one-byte values and, if so, use one-byte operations.
227
« on: August 24, 2014, 02:49:18 pm »
As Hayleia said, I think MemKit covers this. I do agree that the functionalities of MemKit should be added to native Axe, though.
228
« on: August 23, 2014, 12:22:51 pm »
Suggestion for a (very simple) protocol to establish one calculator as a master and the other as a slave: - Wait for a pseudorandom amount of time (to mitigate the chance of both calculators entering the next steps within microseconds of each other).
- Read the link port.
- If in its default state (0b11), pull one line low and wait. This calculator will become the master (or the slave).
- If not in its default state, unless the other calculator is running some other code, this should mean the other calculator is waiting in the state above. Pull the other line low and wait for at least 100 microseconds to make sure the signal is received. This calculator will become the slave (or the master).
- Release the link lines.
All further transmissions can then be guided by each calculator knowing its role in the transmission (sender or receiver).
229
« on: August 23, 2014, 11:52:14 am »
Although having the ability to do this across multiple lines seems appealing for optimization purposes, providing fully manual stack access would be a language design disaster. Ideally, the compiler will eventually be smart enough itself to make the kind of optimizations that tempt this design.
Yes, it's a dangerous command, but advanced developers would then be able to optimize their codes where the compiler isn't smart enough...  But this level of optimization isn't probably needed when using Axe.
If you're advanced enough of a developer that you want manual stack control, inline assembly provides that capability. APD control is a nice idea. AxesOn/AxesOff sort of works due to starting with "A" but otherwise don't really sound right. I also sort of like PwrReg/PwrRegr due to actually meaning something about power. If I were to add this, I'd probably also want to add the ability to instantly power the calculator off, so I'd need to think about some way to represent that as well.
Yes, but then there's the problem of removing the copy of the program (or at least removing its reference inside the VAT, if it's pointed to in the VAT). And there's also another problem : the APD uses the RAM area L1, doesn't it ?
As far as I can tell, you don't need to do anything special for APD to work properly besides enabling it and having the OS interrupt running. I imagine the hardest part of using APD successfully would be making sure other commands used while it's running don't turn it off, whether by disabling interrupts or actually turning off the APD running flag. And yes, APD does write the contents of the screen to L1 when turning the calculator off. I'm pretty sure that's unavoidable. Something else : would it be easy (I don't think so, but I still want to write the idea) to add instructions a bit like #ExprOn and #ExprOff, called #1byte and #2bytes, who force Axe Parser to use A instead of HL for calculations ? Because sometimes only 1 byte is needed, for example and E3C becomes (instead of AND $3C) :
LD H, $00
LD A, L
AND $3C
LD L, A
The current iteration of Axe is entirely built around HL doing everything, so no, this wouldn't be very feasible to add right now. It's been suggested at least once before and is on a to-do list, but is waiting for for the theoretical Axe 2.0 with support for actual data types to break the shackles of everything being a 16-bit int. The token Clear Entries (found in the MEMORY menu) could remove temporary variables (I think that the result of input is stored in a temporary variables, isn't it ?). Also, ClrAllLists could be used to initalise the free RAM areas, from L1 to L6. (See the BCALLs CleanAll and BufClr.)
Being able to remove all temporary variables is of course very easy to implement because it's just B_CALL(_CleanAll). But to be cautious of feature overload, may I ask in what context you imagine an Axe programmer would use this command? Temporary variables should be cleaned up by the OS when execution of your program starts and ends, so I can't think of any reason a program would want to mass delete its temporary variables... except for a shell program that's cleaning up after executing another program, but since vanilla Axe lacks the ability to do many things a shell programs needs already, this doesn't seem like a good enough reason to add it. As for initializing all free RAM areas (to zeroes, I'm assuming): why? I can't imagine a case where this would be necessary. I can only think of a few use cases in which you'd need to initialize any single RAM area to zeroes, and I can't imagine them being needed so severely as to use all six free RAM locations. Even if you did need this, you can clear them manually using a few ClrDraw's and Fill()'s, which is basically all a native command would be doing anyways. I found two different ideas of use for Then : either it could be used to say that the following tokens of the same line should be interpreted only if debugging (by debugging I mean compiling with Zoom), or it could be used to optimize conditional jumps. In this last case, the Then should be used right after a If condition, and should be followed by a Goto instruction : this is roughly the equivalent of ReturnIf, but for jumps. There are some optimizations in assembly to do when Ifs are used to jump only.
Programmers can already use preprocessor conditionals with custom constants to change what code is compiled by simply changing a constant. This can be used in place of knowing the optimization level (which generally doesn't seem like a good idea anyways, as the system for how programs are compiled/optimized is always subject to change). Optimizing if statements that simply perform jumps has been looked into before, but the compiler currently lacks lookahead parsing and a strong peephole optimizer. If either of these is added (which isn't too likely to happen soon because I'm still quite unfamiliar with how the compiler works), then this optimization will surely be added as well. What else... Adding a token (something like FullString) to ignore the split-screen modes...
Like Fullrr? ... a token to generate custom error messages (I can't rememer the BCALL's name), why not using a token like Param which returns the calculator's type (TI-83+, 83+ SE, 84+, ...), another to check the battery level... I think I haven't forgotten anything  !
These all sound very shell-y, which Axe does not aim to natively provide features for. There would be too many features that would need to be added to allow for this very specific type of program to be made in vanilla Axe. By the way, if one day floating numbers are added to Axe, the tokens associated with the variables could be the matrix tokens (from [A] to [J], that is to say 10 variables, and 90 bytes required).
Like 8-bit ints, floating point data types would be added in the theoretical Axe 2.0. You could then name your floating point variables whatever you wanted, like basically every other language.
230
« on: August 21, 2014, 08:11:45 pm »
I'm not sure if I will have to or not. It all depends on what BIOS version my motherboard has. When it comes I'll be able to check it (it has a little sticker on it with BIOS info). If it has version 2, I can get the 4150.
As far as I can tell from Intel's site, the two processors are functionally identical except for the slightly higher clock speed of the 4150. What am I missing?
231
« on: August 21, 2014, 07:16:33 pm »
Why did you downgrade the CPU from 4150 to 4130? Although prices fluctuate, it seems that you can get the 4150 for the same price or even cheaper than the 4130 on average.
232
« on: August 21, 2014, 03:28:57 pm »
Well, if we take the letters as the key's token, approximately one third of the keys won't be covered... yes, it's still too much. Or maybe use i followed by a number, which is the keycode in TI-Basic ? because they're easy to remember, and it'll help people who programmed in TI-Basic to get into Axe.
The assembly key codes follow a pattern that's easy enough to learn, so I don't think this is really necessary. If I did eventually add key equates, I'd probably do it in a much more traditional fashion where the equates are normal constants like any user-defined constant. Some other ideas : rename the RecallGDB and StoreGDB tokens RecallLCD and StoreLCD, and parse them as "L6:Asm(EF7B4C)" and "L3:Asm(EF7B4C)". They would respectively copy the LCD in the main buffer and in the back-buffer, which has many applications and I'm pretty sure it isn't currently possible in pure Axe.
Renaming StoreGDB to StoreLCD is definitely a good idea, and it's so easy to do that I just did it. But instead of using RecallGDB, I think it would make more sense to adopt the syntax used by other screen/buffer commands, like ClrDraw and DrawInv, which is to add an r to operate with the back buffer ( L3) or to add parentheses to operate with an arbitrary buffer. Also, equivalents of the assembly push and pop instructions could be useful (maybe use the nPr and nCr tokens).
This already exists in a functional basis as Select(A,B). Although having the ability to do this across multiple lines seems appealing for optimization purposes, providing fully manual stack access would be a language design disaster. Every language I can think of doesn't provide this functionality for this reason. Ideally, the compiler will eventually be smart enough itself to make the kind of optimizations that tempt this design. Using the APD could be great.
APD control is a nice idea. AxesOn/ AxesOff sort of works due to starting with "A" but otherwise don't really sound right. I also sort of like PwrReg/ PwrRegr due to actually meaning something about power. If I were to add this, I'd probably also want to add the ability to instantly power the calculator off, so I'd need to think about some way to represent that as well. Also, Axe Parser could parse "min(A,B,C)" like "min(A,B):min(,C)" instead of generating the "WRONG # OF ARGS" error (same for other functions like this one).
I was just about to say that this is easily doable... and then I remembered that the signed minimum and maximum commands, min(A,B)r and max(A,B)r, exist. That instantly makes it much harder, because the compiler wouldn't know if normal or signed comparisons are needed until after it has compiled all but the final comparison. This means that I'd either need to create some kind of lookahead capability or create special varargs versions of the commands. Although both sound tricky to implement, the second sounds less tricky and might be manageable. But since the ability to chain these commands already exists and this would only be syntactical sugar, I'm probably not assigning this too high of a priority.
233
« on: August 21, 2014, 11:33:20 am »
By the way, here's another idea of feature : i could be used before a token to return the key's index the token is on. We could write "!If K-i5" instead of "!If K-27" and having to learn all the key's indexes. Additionally, "ir5" would return the key's index of the getKeyr function.
Considering that almost half of the keys don't correspond to actual tokens and couldn't be looked up in this fashion, it doesn't really seem worth doing this to me. We could still find tricks like doubling the ! token means to include it once in the string.
The issue isn't providing a new way for the ! character to be used in strings. The issue is that this will break backwards compatibility because some or all programs that use ! in string data will fail to compile correctly, and backwards compatibility has always been a big goal.
Maybe then you can use one of the tokens that we can find in the "Caractères" menu (available when we use a translating app) ? like the "¿" or the "¡" (not an "i", a reversed "!") for example ?
I don't think this is a good idea : to use these tokens, people would have to install a translating app, 16kb lost, and tokens translated, which is not very convenient for English people. Otherwise, Axe could automatically add this menu in the catalog, which would be a great thing.
I agree that any tokens used by Axe should be enter-able without external tools. Maybe it's time for a catalog hook, though... But making sure it works with localization apps might be tricky. Now that I think about it, the current token hook probably doesn't play nice with localization apps. I should look into that.
234
« on: August 20, 2014, 04:16:20 pm »
The ! idea crossed my mind as well, and would also be a contender for an escape character. But the issue I have with it is that I'd ideally want it whatever token is chosen to be used for other escape sequences as well; being able to use it to include special characters in string data comes to mind. But I'd imagine that it isn't uncommon for ! to be found in string data, and the semantic change would instantly break some or all strings that used it.
235
« on: August 20, 2014, 12:11:15 pm »
They're not used, but I can't say I particularly like them as escape tokens because they're not really symbols. Unfortunately, there aren't many other choices, apart from some clever idea to do it some other way.
EDIT: One "clever idea" I thought of was changing the primary method of displaying a new line on the homescreen to Disp n and claiming i for this. Disp i can be kept as allowed syntax for backwards compatibility, but I like the switch overall. n makes much more sense as a newline character, as the letter is used in many other instances to denote a newline. And although it's still a letter and not a symbol, I'm more comfortable making i the escape token, because it's normal meaning is sort of like a modifier. I'm still not overly keen on this idea, though, as it still isn't an actual symbol and would muddy things up a bit if a future version of Axe called for complex numbers, which isn't that unfathomable if floats were added.
236
« on: August 20, 2014, 11:17:12 am »
A token to ignore the next token doesn't sound like a good idea from a language design standpoint. However, an escape sequence token does. But I have one issue with this: what token do I use? Axe has already used up all the viable symbol tokens that I can think of.
237
« on: August 18, 2014, 06:12:28 pm »
I agree on the text-based source files only, and the editor I'd reccomend is Cemetech's SourceCoder3. I've tried many editors, but SourceCoder seemed to be the best one that I could get to work in Linux.
Why not TokenIDE? An online editor doesn't really mesh well with this. You'd have to constantly be uploading and downloading your sources. As far as I know, TokenIDE should be multi-platform via mono and/or wine.
238
« on: August 18, 2014, 01:16:21 pm »
Is there any particular way in which the two outputs must be separated? Can they just be mushed together like ONE HUNDRED285, or must there be a space or a newline separating them?
239
« on: August 18, 2014, 12:32:52 pm »
The code used to make this run as fast as it does is already ridiculously optimized, beyond what just about everyone besides calc84maniac could produce. Although he has been looking into overhauling the core with a new method of emulation, no positive results have come from it yet. For now, I'd say the code is as fast as (or even faster than) one could reasonably hope for.
The only way to make the emulator run faster currently is to diminish the graphics rendering load. This can be done in two ways: rendering at the native resolution with no upscaling by pressing the - key, or setting a higher frameskip by pressing a higher number key; the number represents the number of frames to skip per frame to render.
240
« on: August 09, 2014, 02:21:56 pm »
Is it okay if the output starts with a newline?
Pages: 1 ... 14 15 [16] 17 18 ... 153
|
Show Posts