• State Not Answered
  • Locked Locked
  • Replies 18 replies
  • Subscribers 21 subscribers
  • Views 4471 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Cygnal constants in upper 64k w/o bankswitching

erik malund

The Cygnal f12x has 128k of flash and using code banking defeats the purpose of using Cygnal. The overhead of banking slows the program down as much as using the Cygnal speed it up.
Thus:

Is there a way in Keil to make all movc a,@a+dptr generated by the compiler/written in assembler access the upper 64k WITHOUT using bankswitching. The Cygnal chip has simple means of data bank select.

in advance thanks,

Erik

Parents
  • 0 in reply to Dejan Durdenic

    Ahhh. The PSBANK register.

    The problem with having a different space for MOVC and instruction fetches is that the compiler stores constants in code space. Changing the target address for MOVC would cause the program to fail. Constant tables are generated by the compiler for all kinds of stuff (like switch statements, jump tables, static arguments, and so on).

    Jon

Reply
  • 0 in reply to Dejan Durdenic

    Ahhh. The PSBANK register.

    The problem with having a different space for MOVC and instruction fetches is that the compiler stores constants in code space. Changing the target address for MOVC would cause the program to fail. Constant tables are generated by the compiler for all kinds of stuff (like switch statements, jump tables, static arguments, and so on).

    Jon

Children
  • 0 in reply to Jon Ward

    "The problem with having a different space for MOVC and instruction fetches is that the compiler stores constants in code space."

    So, does XCONST only affect user constants defined with 'const' in the 'C' source code, and not these compiler-generated "internal" constants?

    If so, sounds like an opportunity for enhancement there...?

  • 0 in reply to Andy Neil

    So, does XCONST only affect user constants defined with 'const' in the 'C' source code, and not these compiler-generated "internal" constants?

    That's correct. The problem with compiler-generated tables is that they are not REALLY part of YOUR data/code. They are an extension of a library routine and, as such, they are all routine-specific.

    For example, one method of switch-case implementation is similar to the following:

    ; Case # stored in registers
LCALL   switch_jump_table_handler
        DW 0005h          ;# cases
        DW case_0_func
        DW case_1_func
        DW case_2_func
        DW case_3_func
        DW case_4_func
; switch_jump_table_handler returns here

    The switch_jump_table_handler function takes the return address, and adds 2* (1 + case #) to get the address of the case function. It then adds 2*cases to the return address and jumps to the case "function". There would probably be little to gain by moving this "constant" stuff into xdata space. There would be more overhead in that the jump table must have a label and now the switch case function must handle generic addresses instead of only code addresses. So, all switch statements implemented this way would suffer a little bit. Also, if there was an XDATA problem, the program would certainly crash in an unexplained way and that would be bad. Jon

  • 0 in reply to Andy Neil

    So, does XCONST only affect user constants defined with 'const' in the 'C' source code, and not these compiler-generated "internal" constants?

    If so, sounds like an opportunity for enhancement there...?

    Amen.

    Allowing ALL non-code to be directed to a given place (upper 64k) would make the Cygnal/Triscend feature extremely useful.

    I appreciate Keils reluctance to include features that only work on selected derivatives, but since Keil with banking as a standard seem to push >64k systems, it would be nice if this non-banking memory expansion could be used.

    Erik