#356 Right operand for GET_VALUE_AT_ADDRESS

hc08 port (9)

Supporting a right operand for GET_VALUE_AT_ADDRESS would result in more efficient code genated for the hc08, which has a suitable x-relative addressing mode. This would help with aggregate and union accesses.



  • Philipp Klaus Krause

    This one is probably the on eoptimization with the highest gain among teh easy-to-implement ones. It would trasform code like

    ; genPlus
    lda *_insertion_sort_sloc0_1_0
    add #_spm_sprites_list
    adc #>_spm_sprites_list
    ; genPointerGet
    ldx ,x


    ; genPointerGet
    ldx *_insertion_sort_sloc0_1_0
    ldx #_spm_sprites_list, x

    Reducing code size from 13 to 5 bytes. And register a is freed, so it can be used for other purposes. This and similar ones are very common code sequences.


  • Erik Petrich

    Erik Petrich - 2012-05-20

    I've implemented the case for a right operand literal in #7741. Still left is the more complicated case of your example, where the right operand would be a rematerializable address of a variable (but I did included support in the low-level loadRegIndexed() to handle this possibility later.)

  • Erik Petrich

    Erik Petrich - 2012-06-05

    With revision #7856, it will handle rematerializable addresses too. However, loop invariance optimization and/or CSE conspire in some cases to move the addition iCode away from the GET_VALUE_AT_ADDRESS iCode, which then leaves an iTemp live across a larger span and is likely to be spilled. Need to find a good away to either prevent to movement of the original addition iCode or determine that the cast/assignment it is turned into can be safely moved back so that the iTemp can be assigned hx instead of spilling. I'll work on optimizing this after the release.

  • Erik Petrich

    Erik Petrich - 2012-06-05
    • assigned_to: nobody --> epetrich

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks