### Author Topic: Basic to ASM?  (Read 6745 times)

0 Members and 1 Guest are viewing this topic.

#### Deep Toaster

• So much to do, so much time, so little motivation
• LV13 Extreme Addict (Next: 9001)
• Posts: 8217
• Rating: +758/-15
##### Re: Basic to ASM?
« Reply #15 on: July 30, 2010, 03:37:56 am »
I don't care if people copy me.    But the 83 idea should work. I don't see why it wouldn't. Too bad I have never seen an 83 in my life.

So apparently, if a TI-83 assembly program starts with
Code: (TI-83 ASM) [Select]
 rst 20h add HL,SP ld E,A.db [program name] ld DE,$D53F ccfit should run from the normal BASIC menu, no weird Send(9prgm or anything. This could be useful. Too bad there aren't that many plain TI-83 users out there anymore I don't know much assembly at all, so here's my n00b question: Could this potentially crash the calculator? Like if we do a rst 20h without knowing what HL is, could that be unstable? « Last Edit: July 30, 2010, 03:52:39 am by Deep Thought » #### thepenguin77 • z80 Assembly Master • LV10 31337 u53r (Next: 2000) • Posts: 1591 • Rating: +823/-5 • The game in my avatar is bit.ly/p0zPWu ##### Re: Basic to ASM? « Reply #16 on: July 30, 2010, 11:14:37 am » If rst 20h is move9ToOp1, then there's not problem there, it's just copying memory. I'm more worried about executing the name. Just because you write .db data, doesn't mean that the calculator knows that it's data. Most of the letter ($40) commands are safe, just ld a, b type stuff. But the numbers would be dangerous. 0 ($30) and 8 ($38) are jr's, 1 and 3 modify sp, 2 i modify's a random byte, and 4, 5, and 6 modify (hl).

But as long as there are no numbers in the name, that will work perfectly.
zStart v1.3.013 9-20-2013
All of my utilities
TI-Connect Help
You can build a statue out of either 1'x1' blocks or 12'x12' blocks. The 1'x1' blocks will take a lot longer, but the final product is worth it.
-Runer112

#### Deep Toaster

• So much to do, so much time, so little motivation
• LV13 Extreme Addict (Next: 9001)
• Posts: 8217
• Rating: +758/-15
##### Re: Basic to ASM?
« Reply #17 on: July 30, 2010, 11:58:06 pm »
Oh yeah, numbers...

I wonder if it's possible for an assembly program to call itself as BASIC. Probably harder, though (with syntax errors ).

EDIT: Anyone want to try? I give up
« Last Edit: July 31, 2010, 12:09:47 am by Deep Thought »

#### Deep Toaster

• So much to do, so much time, so little motivation
• LV13 Extreme Addict (Next: 9001)
• Posts: 8217
• Rating: +758/-15
##### Re: Basic to ASM?
« Reply #18 on: November 03, 2010, 07:44:40 pm »
*bump*

Sorry for the late post, but just found out it's impossible. The TI-83 can only run unsquished code (written in ASCII hex), but not normal ASM programs (why, TI? ) So there's no way to run it as BASIC.
« Last Edit: November 03, 2010, 07:44:49 pm by Deep Thought »

#### guy6020665

• LV6 Super Member (Next: 500)
• Posts: 481
• Rating: +7/-1
##### Re: Basic to ASM?
« Reply #19 on: November 03, 2010, 09:21:51 pm »
I've been wondering, when you run a BASIC program the calculator parses as it goes right?

If so wouldn't it be theoretically possible to just have another program parse a BASIC program and output it as an ASM program using the same method? (Kind of like Axe only just faster BASIC)
« Last Edit: November 03, 2010, 09:22:11 pm by guy6020665 »

#### AngelFish

• Is this my custom title?
• LV12 Extreme Poster (Next: 5000)
• Posts: 3242
• Rating: +270/-27
• I'm a Fishbot
##### Re: Basic to ASM?
« Reply #20 on: November 03, 2010, 10:23:30 pm »
I've been wondering, when you run a BASIC program the calculator parses as it goes right?

If so wouldn't it be theoretically possible to just have another program parse a BASIC program and output it as an ASM program using the same method? (Kind of like Axe only just faster BASIC)

In theory, yes. But it'd be really difficult because  don't think what the OS interpreter does is perfectly repetitive. I'm fairly sure it does some code swapping too, which would be difficult to parse without an on-calc compiler. Having it on-calc presents it's own problems though.
∂²Ψ    -(2m(V(x)-E)Ψ
---  = -------------
∂x²        ℏ²Ψ

#### meishe91

• Super Ninja
• LV11 Super Veteran (Next: 3000)
• Posts: 2946
• Rating: +115/-11
##### Re: Basic to ASM?
« Reply #21 on: November 04, 2010, 12:05:36 am »
I believe I asked the same question a while ago. Whether it's possible to pre-parse a TI-BASIC program to have it run faster? If I remember correctly I think someone said it would actually be the exact same speed if you did manage to pre-parse it correctly, which in itself is extremely hard if not impossible.
Spoiler For Spoiler:

For the 51st time, that is not my card! (Magic Joke)

#### DJ Omnimaga

• Clacualters are teh gr33t
• CoT Emeritus
• LV15 Omnimagician (Next: --)
• Posts: 55935
• Rating: +3153/-232
• CodeWalrus founder & retired Omnimaga founder
##### Re: Basic to ASM?
« Reply #22 on: November 04, 2010, 12:46:22 am »
One thing: I can't imagine how large a BASIC program would become if it was translated to a compiled-style program but with the slowness of BASIC.

#### meishe91

• Super Ninja
• LV11 Super Veteran (Next: 3000)
• Posts: 2946
• Rating: +115/-11
##### Re: Basic to ASM?
« Reply #23 on: November 04, 2010, 01:05:54 am »
Ya, I don't know.

One thing that could technically work, in theory, is if someone did something like Axe Parser. Go through each command and write a Assembly routine that does the exact same thing, just faster. Then just run the TI-BASIC program through this new parser and bang, a TI-BASIC program with much faster speed. That parser would be a nightmare to code though.
Spoiler For Spoiler:

For the 51st time, that is not my card! (Magic Joke)

#### AngelFish

• Is this my custom title?
• LV12 Extreme Poster (Next: 5000)
• Posts: 3242
• Rating: +270/-27
• I'm a Fishbot
##### Re: Basic to ASM?
« Reply #24 on: November 04, 2010, 01:16:05 am »
One thing: I can't imagine how large a BASIC program would become if it was translated to a compiled-style program but with the slowness of BASIC.

If you compile BASIC, you're removing the overhead of the Interpreter which probably has to look through a database of all of the commands and execute the right one. Doing that ahead of time with a compiler would blow up your file size like Axe does, except that the compiled language would be even larger than an equivalent Axe program because of the floating point calculations.

Some parts of the parser wouldn't be too difficult, such as the Pause command or the Vertical/Horizontal commands, because those are simply B_calls that you feed the arguments into through the registers.

Thinking about it, one could potentially write a reasonably sized compiler/interpreter that would take some of those easy commands and turn them into Assembly library type commands.
« Last Edit: November 04, 2010, 01:17:07 am by Qwerty.55 »
∂²Ψ    -(2m(V(x)-E)Ψ
---  = -------------
∂x²        ℏ²Ψ

#### meishe91

• Super Ninja
• LV11 Super Veteran (Next: 3000)
• Posts: 2946
• Rating: +115/-11
##### Re: Basic to ASM?
« Reply #25 on: November 04, 2010, 01:22:58 am »
The thing though is that it's not those easy, simple commands that are the issue. It's things like seq( and such. Pause, Horizontal, Vertical, and like commands are relatively ok in TI-BASIC so I wouldn't see much of a point for Assembly routines for things like those.
Spoiler For Spoiler:

For the 51st time, that is not my card! (Magic Joke)

#### DrDnar

• LV7 Elite (Next: 700)
• Posts: 546
• Rating: +97/-1
##### Re: Basic to ASM?
« Reply #26 on: November 04, 2010, 01:24:01 am »
The floating point math is definitely a weak point. Using floating point math for For( loops and in other places wastes a lot of CPU power. You'd need a way to inform your compiler that certain variables in certain places can be handled with 8- or 16-bit integer arithmetic.
"No tools will make a man a skilled workman, or master of defense, nor be of any use to him who has not learned how to handle them, and has never bestowed any attention upon them. . . . Yes, [] the tools which would teach men their own use would be beyond price."—Plato's The Republic, circa 380 BC

#### AngelFish

• Is this my custom title?
• LV12 Extreme Poster (Next: 5000)
• Posts: 3242
• Rating: +270/-27
• I'm a Fishbot
##### Re: Basic to ASM?
« Reply #27 on: November 04, 2010, 01:42:25 am »
@Meishe91

You're right. The commands that are easily hard coded are the ones that are the slowest. That's probably because they're the ones that have the smallest routines. I'm sure that that things like Rand could be done in Assembly with the proper alterations. Axe executes that command very quickly. Also, TI probably made B_calls out of the majority of them, seeing as how lazy some of the other B_calls are written. For example, B_call (5089) is literally five lines of Assembly.
∂²Ψ    -(2m(V(x)-E)Ψ
---  = -------------
∂x²        ℏ²Ψ

#### DJ Omnimaga

• Clacualters are teh gr33t
• CoT Emeritus
• LV15 Omnimagician (Next: --)
• Posts: 55935
• Rating: +3153/-232
• CodeWalrus founder & retired Omnimaga founder
##### Re: Basic to ASM?
« Reply #28 on: November 04, 2010, 04:27:46 am »
One thing: I can't imagine how large a BASIC program would become if it was translated to a compiled-style program but with the slowness of BASIC.

If you compile BASIC, you're removing the overhead of the Interpreter which probably has to look through a database of all of the commands and execute the right one. Doing that ahead of time with a compiler would blow up your file size like Axe does, except that the compiled language would be even larger than an equivalent Axe program because of the floating point calculations.

Some parts of the parser wouldn't be too difficult, such as the Pause command or the Vertical/Horizontal commands, because those are simply B_calls that you feed the arguments into through the registers.

Thinking about it, one could potentially write a reasonably sized compiler/interpreter that would take some of those easy commands and turn them into Assembly library type commands.
Oh I meant about literally including the needed TI-BASIC interpreter code (from the TI-OS) in the BASIC program that is compiled into assembly. Now that would be huge I am sure.
The floating point math is definitely a weak point. Using floating point math for For( loops and in other places wastes a lot of CPU power. You'd need a way to inform your compiler that certain variables in certain places can be handled with 8- or 16-bit integer arithmetic.
True, I remember a discussion on MaxCoderz a while ago with Kozak, who was working on an RPG, and he said he noticed a considerable speed difference when he tried using them instead of integers for certain things.

Another thing that makes BASIC slow is how the LCD is updated every Line/Pixel command. I am sure it would still be slow if it wasn't, but I am sure it would be much faster. In Axe, a program that fills the screen pixel by pixel almost runs as slow as TI-BASIC when you update the screen every frame. If you only update the screen at the very end, it almost takes an instant.
« Last Edit: November 04, 2010, 04:31:50 am by DJ Omnimaga »

#### Deep Toaster

• So much to do, so much time, so little motivation