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
Can I tell the compiler to forget about banking, and let the linker locate constants in 64-96k The problem is that there are no instructions or addressing mode of the Cygnal part for accessing 17 bits of address space. Addressing larger than 16-bit addresses must be done in software. The way this is done is by setting the COBANK sfr to the bank number (0-3) and setting the address (in DPTR). The compiler does not intrinsicly KNOW about the COBANK sfr. That's why the XBANKING.A51 file is required. This file allows you to use just about any memory banking scheme. If you don't want to use it, you can easily create your own scheme of setting the COBANK sfr and reading memory. However, you'll have to manage all of it. Jon
"The problem is that there are no instructions or addressing mode of the Cygnal part for accessing 17 bits of address space." Same with Triscend. "The way this is done is by setting the COBANK sfr to the bank number (0-3) and setting the address (in DPTR)." Triscend does it via the Address Mappers. "The compiler does not intrinsicly KNOW about the COBANK sfr." Similarly for Triscend's Address Mappers. "If you don't want to use it, you can easily create your own scheme of setting the COBANK sfr and reading memory. However, you'll have to manage all of it." Yep, that's the way I do it on the Triscend. Thus it sounds to me like a very similar approach should work with Cygnal.
The problem is that there are no instructions or addressing mode of the Cygnal part for accessing 17 bits of address space. Addressing larger than 16-bit addresses must be done in software. Incorrect, if the compiler/linker allowed it. The Cygnal (and based in the above the Triscend as well) have the ability to read data from one half and instructions from the other half of the 128k.
The Cygnal (and based in the above the Triscend as well) have the ability to read data from one half and instructions from the other half of the 128k. I'm not sure I understand what you are saying. Are you saying that the Cygnal devices fetch program code for address 0x0000 from one physical memory address but retrieve code using MOVC from address 0x0000 from a different physical memory address? If that's the case, then this is a feature no one could possibly use. Static jump tables would not work with this scenario. Neither would tables of function pointers and so on. I didn't get this from the Cygnal documentation but maybe I'm not reading the right part. Nonetheless, I still stand by my previous statement that, "...there are no instructions or addressing mode of the Cygnal part for accessing 17 bits of address space. Addressing larger than 16-bit addresses must be done in software." Jon
Actually, only devices with 128K of flash can do that (F12x family) - you can programm page register to fetch opcodes from one bank and to fetch movc data from another...If you are careful, you use that as an advantage in the scenario Erik proposed... - Dejan
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
"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...?
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
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