Quote from: ACagliano on October 05, 2010, 10:22:27 am

@LordConupiter: Not 2 calc data sending. I'm talking about having the ability to run other programs from an Axe compiled program.

did you mean that! sorry, I misinterpreted your Post, for U suggested to use the Get command, and that's already used for data transfer between 2 calcs.

@Runer: how did you do that! those two code block next to each other?

A table:
[table][tr][td]Put one code block in here[/td][td]        [/td][td]Put another code block in here[/td][/tr][/table]

Feature Request:

TI-Basic has the ability to transfer control to another executable, then return when done. Axe should be able to do the same. Maybe, use the command Get( or something, where the command

Get(prgmAAA)

would cause the executable to transfer execution to the asm program AAA, then return to the main.

If you want to call another Axe program, unless you desperately need them to be two separate compiled programs, this can already be achieved with included programs. Just call it as a subroutine in your main program without a Return, like this:

Code: (Your main program) [Select] .PROGRAM ClrHome Disp "Hello " sub(A) Disp i Return Lbl A prgmINCLUDE

Code: (prgmINCLUDE) [Select] .. Disp "world!" Return

It probably doesn't work because, as of now, there's only a SortD() command

Here's a very compact 125-byte library for hex display. It contains the following subroutines:

• N2H: Nibble to hex – Example: 13sub(N2H) would return the character "D"
• B2H: Byte to hex – Example: sub(B2H,69) would return a pointer to the string "45"
• W2H: Word (2 bytes) to hex – Example: sub(W2H,1234) would return a pointer to the string "04D2"
  

To include it in your program, send prgmHEXLIB to your calculator and put prgmHEXLIB among the other subroutines in your program. Just make that sure wherever you put it, it won't be accidentally reached and executed unless you call it.

I challenge anyone to find a single optimization in this code or produce a smaller library of their own (/me waits for Quigibo to make it way more compact than anyone thought possible)


EDIT: Changed name from prgmHEXSRC to prgmHEXLIB and reuploaded. This name just seems more appropriate for a library that you don't compile as a standalone program.

ASM is a totally different animal from BASIC. But the ASM jump commands I'm familiar with, JL and JP both take fairly long times to jump as far as I'm aware. I'm not sure if Axe uses those commands for GOTO though.

JR and JP take 12 clock cycles at most. That's 2 microseconds (2*10^-6 seconds) at 6MHz, so I would hardly call that a "fairly long time."

Yeah, that would probably do it But why would A° even compile successfully for that matter?

≥≥0 definitely requires code, as it needs to check the sign bit and return it's inverse. And I'm also wondering why ≥≥CONST is 11 bytes larger than ≥≥0, because it seems to me that it could be optimized to just combine -CONST and ≥≥0 and only be 4 bytes larger.

While we're on the topic of optimizations... Would something like A-128≥≥0 be more optimized than A≥≥128? And if so, why is the ≥≥CONST entry in Auto Opts.txt listed as taking a whole 11 bytes more than ≥≥0?