That is probably what I am going to do.
Kerm we are going to also have to rework the Calcnet onkey handler again. I'm Thinking something closer to how Ti's hooks work might be suitable.
I'm still more than willing to chain with the OS interrupt, if it will make life easier for us, as long as the OS interrupt doesn't do weird things when it APDs. Definitely bears further experimentation.
You store the calcnet interrupt handler in SaveSscreen if the tios apd fires it will be overwritten if I remember correctly (I might be wrong its been a while). I personally do not have a problem chaining the os interrupt as well. I just see it leading to possible problems. If the basic parser does not need IM1 active imo we should just do without.
As I get time I am going to start profiling C3 code and see what can be slimmed down or de-implemented for lack of use. (I can only name 1 function for real on that list. but yeah.)
EDIT: I removed a bunch of stuff from c3_std that had no label references anywhere else in c3 and I shaved off 753 bytes of unused stuff. Going to keep looking c3 had a lot of unimplemented ideas as it was iambians code playground so to speak. as of right now we have 1007 bytes free on page 2 that *should* be enough to make this work. (supposing I didnt break anything lol)
Also for c3 libs do we want to profile for size or for speed?
You probably oughta find a test suite for that.
Elfprince i'm going to search through the code now. But its not referenced anywhere else in dcs so Unless Iambian was doing some funky preprocessor allocation. It should be good.
Hopefully
More space in DCS is always good.
I'm just preemptively pointing out that what you're saying sounds suspiciously like a precursor to the first stage of debugging, and hoping it'll save you some time in the case that things start acting weird.
- That can't happen. <- you are here
- That shouldn't happen.
- Hmmm, weird.
- Why does that happen?
- Oh, I see.
- How did that ever work?
I would actually be on step 2.5 cause if shouldn't happen unless Iambian went insane working on this. In which I'm closer to hmm weird because its just a cluster***** of undynamic code location insanity. In which I will probably implode on realization.
In english. Gonna profile and pray lol.
Geekboy, can you please give me a list and/or a diff of the things that you removed, so I can ensure it's stuff that wasn't surreptitiously and sneakily called from elsewhere?
Kerm can you please add in Get( and Send( to the parser hook and link me the diff I can't make heads or tails of what is going on there.
geekboy1011 wrote:
Kerm can you please add in Get( and Send( to the parser hook and link me the diff I can't make heads or tails of what is going on there.
I would prefer to use one of the existing hooked tokens if you don't object, like sum().
That would look so silly though. Get( and Send( are semantically meaningful, and unlikely to conflict with any other parser hooks out there. *I* would prefer not to end up with another scenario like the xlib/Symbolic/Omnicalc fiasco.
elfprince13 wrote:
That would look so silly though. Get( and Send( are semantically meaningful, and unlikely to conflict with any other parser hooks out there. *I* would prefer not to end up with another scenario like the xlib/Symbolic/Omnicalc fiasco.
I hear that and understand. I have two concerns:
(1) The more tokens you overload, the more (slightly) slower BASIC programs get, because the parser hook will have to check for more tokens to override on every single token, all of which run through the parserhook before being interpreted normally.
(2) I don't want to get into Axe Syndrome, where every token is overloaded to do something else.
I can appreciate if you think that just overloaded Get( and Send( won't lead us too far down either of those paths.
KermMartian wrote:
elfprince13 wrote:
That would look so silly though. Get( and Send( are semantically meaningful, and unlikely to conflict with any other parser hooks out there. *I* would prefer not to end up with another scenario like the xlib/Symbolic/Omnicalc fiasco.
I hear that and understand. I have two concerns:
(1) The more tokens you overload, the more (slightly) slower BASIC programs get, because the parser hook will have to check for more tokens to override on every single token, all of which run through the parserhook before being interpreted normally.
(2) I don't want to get into Axe Syndrome, where every token is overloaded to do something else.
I can appreciate if you think that just overloaded Get( and Send( won't lead us too far down either of those paths.
1) What are the token numbers you're checking for? The argument I was having with kllrnohj about if vs switch and multiway branching is directly applicable here. Doing this as a switch or a balanced tree rather than serial conditions would be much more performant.
2) I don't think this would lead too far down that path. Get( and Send( are essentially never used anyway, so this isn't obscuring real world code usages.
I started implementing this and found why using Get/Send is a bad idea. Check out what WikiTI says:
Quote:
Class 2 Functions
These include most "programming" commands. No arguments are parsed.
You may, if you are prepared to face the consequences, attempt to read the arguments yourself. The undocumented B_CALL IncFetch can be useful in doing so.
If you return Z, the parser will run the function normally. If you return NZ, the parser will continue execution from where you left off.
Parsing all the arguments manually is not really what I want to spend all the newly-freed space on.
My vote use what ever you think is best. Just tell me what they are lol. And point me to a page showing me how to handle arguments. And I could care less lol
Out of curiosity
Quote:
Class 1 Functions
Class 1 tokens all take some positive number of arguments (zero arguments is a syntax error.) These are separated by commas, or in the case of binary operators, by the operator itself. All of the arguments are evaluated before the function is.
The arguments are placed on the FPS in "reverse" order. That is to say, the earliest argument read is deepest in the stack. The final argument is in OP1. The total number of arguments is passed in HL.
Any of the following data types may be used (except where prohibited by syntax rules): Real, List, Matrix, Equation, String, Complex, Complex List. Real numbers are stored on the stack as floating-point. Complex numbers are stored as two consecutive stack entries or in OP1 and OP2 (see the SDK documentation for Push/Pop OP1/3/5.) Other data types are stored as variable names.
A hook may do any of the following:
Leave all arguments as is, and return Z.
Modify arguments, or add or remove them while updating HL appropriately, and return Z.
Remove all arguments from the FPS, place the result of your computation in OP1, and return NZ.
Remove all arguments from the FPS, reset numOP1,(iy+ParsFlag2), and return NZ. (This is generally preferable if you are not returning a useful value, as it will preserve Ans.)
Class 2 Functions
These include most "programming" commands. No arguments are parsed.
You may, if you are prepared to face the consequences, attempt to read the arguments yourself. The undocumented B_CALL IncFetch can be useful in doing so.
If you return Z, the parser will run the function normally. If you return NZ, the parser will continue execution from where you left off.
Class 3 Functions
If very little is known about class 2, less is known about class 3. Tentatively, it looks like the class 2 functions that you would expect to be class 1 have class 3 secondary callbacks.
It looks like the parameters are stored in OP1 and the FPS as in class 1 and the number of arguments is stored at 9661. HL is the same as (OPS) and should be saved.
Do we have a way to test if Get( and Send( have class 3 secondary callbacks?
Elfprince: Yes, we do, and I've tested, and they don't. Sadly.
Geekboy: I have checked in my code. The three functions (Cn2Get, Cn2Send, and Cn2Stop have dummies at the bottom of dcsblibs.asm. I have also documented them on the DCS Wiki. We need to figure out how to return both the sender address and message for sum(18) (Get).
bummer...oh well.
Also, fixed your post to disable smilies.
Maybe you should have it accept two list names? One for the sender address, and one for the data to be dumped into? What's the largest allowed # of bytes in a calcnet frame? Less than 999?
I personally would have then pass a string or list for the sender ID and a list for the data simple and effective
I think string IDs would be better. I'm planning on having programs pass around both messages and addresses as strings; I think that would be the most intuitive.
