• Axe Parser 5 1
Currently:  

Author Topic: Axe Parser  (Read 551689 times)

0 Members and 2 Guests are viewing this topic.

Offline Deep Toaster

  • So much to do, so much time, so little motivation
  • Administrator
  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 8217
  • Rating: +758/-15
    • View Profile
    • ClrHome
Re: Axe Parser
« Reply #885 on: June 26, 2010, 01:22:57 am »
Also, is there a way to use the variables A through Z and Θ as 8-bit data? I've used up all of them, and I'm resorting to using data in from L1 onwards, even though most of the bytes are still empty since most of the data could have been 8-bit numbers.




Offline Builderboy

  • Physics Guru
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 5673
  • Rating: +613/-9
  • Would you kindly?
    • View Profile
Re: Axe Parser
« Reply #886 on: June 26, 2010, 02:43:47 pm »
As far as i know, no.  Since whenever you store to a variable, it updates all 16 bits, clearing out any data you would want to store elsewhere.  If you really really really wanted to you could write your own routine to store and retrieve from the variable locations, but thats only if you really want those 27 extra bytes :P

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55943
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Axe Parser
« Reply #887 on: June 26, 2010, 02:47:02 pm »
would storing to the first byte of A be for example 0->{A} and the 2nd byte 0->{A+1}?

Offline Builderboy

  • Physics Guru
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 5673
  • Rating: +613/-9
  • Would you kindly?
    • View Profile
Re: Axe Parser
« Reply #888 on: June 26, 2010, 02:49:41 pm »
Not quite, since A is the number of the variable, not the location.  A is located at location 34542, or more commonly known as L1-54.

0->{L1-54}   and 0->{L1-53} i believe would work.

Offline Quigibo

  • The Executioner
  • CoT Emeritus
  • LV11 Super Veteran (Next: 3000)
  • *
  • Posts: 2031
  • Rating: +1075/-24
  • I wish real life had a "Save" and "Load" button...
    • View Profile
Re: Axe Parser
« Reply #889 on: June 26, 2010, 02:52:14 pm »
Don't use that method long term.  The location of the variables will eventually be switching to a different location at the end of L1 instead of the beginning.
___Axe_Parser___
Today the calculator, tomorrow the world!

Offline Builderboy

  • Physics Guru
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 5673
  • Rating: +613/-9
  • Would you kindly?
    • View Profile
Re: Axe Parser
« Reply #890 on: June 26, 2010, 02:55:42 pm »
Whats the reason for moving them?

Offline calc84maniac

  • eZ80 Guru
  • Coder Of Tomorrow
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2912
  • Rating: +471/-17
    • View Profile
    • TI-Boy CE
Re: Axe Parser
« Reply #891 on: June 26, 2010, 03:02:36 pm »
It was my suggestion, so that when he eventually makes 8-bit math mode it can decrease code size a bit (because the end of L1 is next the system flags area)
"Most people ask, 'What does a thing do?' Hackers ask, 'What can I make it do?'" - Pablos Holman

Offline Quigibo

  • The Executioner
  • CoT Emeritus
  • LV11 Super Veteran (Next: 3000)
  • *
  • Posts: 2031
  • Rating: +1075/-24
  • I wish real life had a "Save" and "Load" button...
    • View Profile
Re: Axe Parser
« Reply #892 on: June 26, 2010, 03:04:09 pm »
There is a size optimization I can do when I get to doing byte mode which allows me to reference the variables from a relative location using the IY register instead of an absolute location.  This is becasue IY is located slightly after the free ram area in L1 for normal OS uses.  I'm still not 100% sure I will have time for that in Axe 1.0.0 because it might end up being a 2.0.0 thing if I don't have time to finish it.  Its an ambitious feature requiring the addition of many new routines.

EDIT: Ninja'd  Maybe I'll move them now as a precaution so that people can use the L1 hack to reference them more reliably.
« Last Edit: June 26, 2010, 03:05:00 pm by Quigibo »
___Axe_Parser___
Today the calculator, tomorrow the world!

Offline calc84maniac

  • eZ80 Guru
  • Coder Of Tomorrow
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2912
  • Rating: +471/-17
    • View Profile
    • TI-Boy CE
Re: Axe Parser
« Reply #893 on: June 26, 2010, 03:06:38 pm »
There is a size optimization I can do when I get to doing byte mode which allows me to reference the variables from a relative location using the IY register instead of an absolute location.  This is becasue IY is located slightly after the free ram area in L1 for normal OS uses.  I'm still not 100% sure I will have time for that in Axe 1.0.0 because it might end up being a 2.0.0 thing if I don't have time to finish it.  Its an ambitious feature requiring the addition of many new routines.

EDIT: Ninja'd  Maybe I'll move them now as a precaution so that people can use the L1 hack to reference them more reliably.
Actually, maybe you could make a way in the parser to reference variable locations so it will never break things. Perhaps the lowercase versions?
"Most people ask, 'What does a thing do?' Hackers ask, 'What can I make it do?'" - Pablos Holman

Offline Quigibo

  • The Executioner
  • CoT Emeritus
  • LV11 Super Veteran (Next: 3000)
  • *
  • Posts: 2031
  • Rating: +1075/-24
  • I wish real life had a "Save" and "Load" button...
    • View Profile
Re: Axe Parser
« Reply #894 on: June 26, 2010, 03:13:14 pm »
That would be clever!  However, I am probably going to be using more lowercase characters to prefix more constant types like key codes, bcalls, tokens, useful ram pointers, etc.  But I could do the same thing.  Like maybe pA gets compiled as "Pointer to A" so you can do {pA} to get it.
___Axe_Parser___
Today the calculator, tomorrow the world!

SirCmpwn

  • Guest
Re: Axe Parser
« Reply #895 on: June 26, 2010, 06:17:40 pm »
If you are using lowercase tokens, you may want to modify the token hook to replace the two byte lowercase letters TIOS makes with proper one byte letters, and make the token hook display them correctly.

Offline Builderboy

  • Physics Guru
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 5673
  • Rating: +613/-9
  • Would you kindly?
    • View Profile
Re: Axe Parser
« Reply #896 on: June 26, 2010, 07:19:13 pm »
How would it know the difference between lowercase and uppercase then?  Since they would be using the same token o.O

SirCmpwn

  • Guest
Re: Axe Parser
« Reply #897 on: June 26, 2010, 07:22:22 pm »
No, I mean that 40h and forward are lowercase characters outside of TI Basic, in the normal ASCII set.  The TIOS TI Basic editor is not regular ASCII, but tokenized.  The equivalent of 40h in ASCII is "a", but gibberish in TI Basic.  TI Basic lowercase tokens take up two bytes.  60h and forward are uppercase characters, so one byte lowercase characters are possible, assuming Axe makes up for it.
This will, however, make it near impossible to modify Axe Basic code that uses lowercase letters without the token hook installed.

Offline calc84maniac

  • eZ80 Guru
  • Coder Of Tomorrow
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2912
  • Rating: +471/-17
    • View Profile
    • TI-Boy CE
Re: Axe Parser
« Reply #898 on: June 26, 2010, 07:30:31 pm »
No, I mean that 40h and forward are lowercase characters outside of TI Basic, in the normal ASCII set.  The TIOS TI Basic editor is not regular ASCII, but tokenized.  The equivalent of 40h in ASCII is "a", but gibberish in TI Basic.  TI Basic lowercase tokens take up two bytes.  60h and forward are uppercase characters, so one byte lowercase characters are possible, assuming Axe makes up for it.
This will, however, make it near impossible to modify Axe Basic code that uses lowercase letters without the token hook installed.
I don't really see much point in this. First of all, they won't be used very much in the source and secondly, there won't be any size change in the executable. Also, "A" is 41h in ASCII and so is the TI-Basic token. "a" is 61h in ASCII.
"Most people ask, 'What does a thing do?' Hackers ask, 'What can I make it do?'" - Pablos Holman

Offline Builderboy

  • Physics Guru
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 5673
  • Rating: +613/-9
  • Would you kindly?
    • View Profile
Re: Axe Parser
« Reply #899 on: June 26, 2010, 07:37:02 pm »
No, I mean that 40h and forward are lowercase characters outside of TI Basic, in the normal ASCII set.  The TIOS TI Basic editor is not regular ASCII, but tokenized.  The equivalent of 40h in ASCII is "a", but gibberish in TI Basic.  TI Basic lowercase tokens take up two bytes.  60h and forward are uppercase characters, so one byte lowercase characters are possible, assuming Axe makes up for it.
This will, however, make it near impossible to modify Axe Basic code that uses lowercase letters without the token hook installed.

Mmm i dont see how this would work.  I think you might be mixing up characters and tokens.  Tokens are what the editor uses, characters are only what the tokens are made out of.  Are you suggesting overriding 26 tokens with new character sets?