So the declarations of the functions receive also the currentCodeSegment, but only when the function is defined, the currentCodeSegment is to be assigned to the function (procedure!). During declaration of functions the code segment is likely Code ...
- Renamed #pragma far() to #pragma bank() upon design recommendations of @jesper.
- renamed #pragma near to #pragma nobank, to avoid using bank(-1).
- renamed __far directive to __bank directive.
- introduced bank area upon design recommendation of jesper, and replaced this with the already present code segment linkage to banking. So the structured stayed the same, only the naming changed! This unlink from segment indeed makes things easier when no segments are in scope of the program.
- added bank area as part of the fragment signature, so now call_far_[platform]_[bankarea]_prepare.asm, call_far_[platform]_[bankarea]_execute.asm, call_far_[platform]_[bankarea]_finalize.asm are expected to be present in the compiler.
- removed the c code prepare, execute, finalize idea. The fragments seem to be enough for the moment.
- added ram and rom fragments for far calls for the cx16.
- Cleaned banking logic from Statement level.
- Refactored pragmaCodeSegs HashMap, which has been removed from Pass0GenerateStatementSequence and moved to Program. It controls which code segment have been defined, and a validation is implemented in the far_seg pragmas.
- Refactored __far() to use the code segments, in analogy to far_seg pragmas.
- Refactored Procedure, which implements functions to use the FarSegment to decide on far declaration and far bank retrieval.
- refactored CallingConvention. Removed earlier quick implementation of bankFar variable as a local property, and declaredFar in the Procedure class. Now everyting is controlled through the farSegment.
- Refactored Procedure, the removal of FAR_CALL calling convention. It is wrong to implement FAR_CALL calling convention, because far and near calls can be stack calls, phi calls and even a varcall can be near of far.
- Removed the Pass1ProcedureFar because far and near implementation is not defined in statement level, it is defined on procedure level. But I've kept Pass1ProcedureFar to suppor the logic for inline prepare, execute, finalize routines during further implementation.
- Refactored directive FAR to match the directive far_seg() structure.
- Refactored complete logic during Pass4CodeGeneration to process statement call fragment generation to decide on near or far calls within the logic, taking into account the calling convention used.
- Added new fragments call_far[platform]_prepare.asm, call_far[platform]_execute.asm, call_far[platform]_finalize.asm and deleted call_far[platform]_entry.asm, call_far[platform]_exit.asm
- Renamed pragmas far_seg and near_seg to simply far and near respectively. Updated test cases with this change.
- Added test cases.
TODO: The actual inline implementation of prepare, execute, finalize functions when platform .asm fragments are not used.
TODO: Implementation of the near directive.
#pragma far_seg(segment, bank, call_prepare, call_execute, call_finalize)
with variable parameters, other option is:
#pragma far_seg(segment, bank)
After parsing a FarSegment HashMap is created that is later used for the far or near call determination.
Added currentFarSegment variable.
Added near in KickCLexer for __near directive.
Added far_seg and near_seg #pragma keywords.
near_seg is to be parsed in the next commit.
- far calls are now ALL iterated and flagged with a bank!
- procedure objects are taken as the base for far call asm generation, not the call objects anymore (too tricky). But i have kept the call objects to be also updated with the bank for any reference later!
- far calls are now ALL iterated and flagged with a bank!
- procedure objects are taken as the base for far call asm generation, not the call objects anymore (too tricky). But i have kept the call objects to be also updated with the bank for any reference later!
