%option splitarrays now also at module level

This commit is contained in:
Irmen de Jong 2023-05-31 21:50:41 +02:00
parent 24fc95ac81
commit bb35a80177
6 changed files with 26 additions and 22 deletions

View File

@ -283,10 +283,9 @@ fun determineCompilationOptions(program: Program, compTarget: ICompilationTarget
val launcherTypeStr = launcherDirective?.args?.single()?.name?.uppercase()
val zpoption: String? = (toplevelModule.statements.singleOrNull { it is Directive && it.directive == "%zeropage" }
as? Directive)?.args?.single()?.name?.uppercase()
val allOptions = program.modules.flatMap { it.statements }.filter { it is Directive && it.directive == "%option" }
.flatMap { (it as Directive).args }.toSet()
val floatsEnabled = allOptions.any { it.name == "enable_floats" }
val noSysInit = allOptions.any { it.name == "no_sysinit" }
val allOptions = program.modules.flatMap { it.options() }.toSet()
val floatsEnabled = "enable_floats" in allOptions
val noSysInit = "no_sysinit" in allOptions
val zpType: ZeropageType =
if (zpoption == null)
if (floatsEnabled) ZeropageType.FLOATSAFE else ZeropageType.KERNALSAFE

View File

@ -168,8 +168,12 @@ class AstPreprocessor(val program: Program,
return makeSplitArray(decl)
}
if("splitarrays" in decl.definingBlock.options() && (decl.datatype==DataType.ARRAY_W || decl.datatype==DataType.ARRAY_UW))
return makeSplitArray(decl)
if(decl.datatype==DataType.ARRAY_W || decl.datatype==DataType.ARRAY_UW) {
if ("splitarrays" in decl.definingBlock.options())
return makeSplitArray(decl)
if("splitarrays" in decl.definingModule.options())
return makeSplitArray(decl)
}
return noModifications
}

View File

@ -312,7 +312,7 @@ open class Module(final override var statements: MutableList<Statement>,
override fun toString() = "Module(name=$name, pos=$position, lib=${isLibrary})"
override fun referencesIdentifier(nameInSource: List<String>): Boolean = statements.any { it.referencesIdentifier(nameInSource) }
fun options() = statements.filter { it is Directive && it.directive == "%option" }.flatMap { (it as Directive).args }.map {it.name!!}.toSet()
fun accept(visitor: IAstVisitor) = visitor.visit(this)
fun accept(visitor: AstWalker, parent: Node) = visitor.visit(this, parent)

View File

@ -129,7 +129,7 @@ Directives
- ``align_word`` (in a block) will make the assembler align the start address of this block on a word boundary in memory (so, an even memory address).
- ``align_page`` (in a block) will make the assembler align the start address of this block on a page boundary in memory (so, the LSB of the address is 0).
- ``merge`` (in a block) will merge this block's contents into an already existing block with the same name. Useful in library scenarios.
- ``splitarrays`` (in a block) makes all word-arrays in this block lsb/msb split arrays (as if they all have the @split tag). See Arrays.
- ``splitarrays`` (block or module) makes all word-arrays in this scope lsb/msb split arrays (as if they all have the @split tag). See Arrays.
.. data:: %asmbinary "<filename>" [, <offset>[, <length>]]

View File

@ -17,17 +17,8 @@ For 9.0 major changes
- DONE: added sys.irqsafe_xxx irqd routines
- DONE: added gfx2.fill() flood fill routine
- DONE: added @split storage class for (u)word arrays to store them as split lsb/msb arrays which is more efficient (but doesn't yet support all array operations)
- DONE: added -splitarrays command line option to treat all word arrays as tagged with @split
- DONE: added -splitarrays command line option and '%option splitarrays' to treat all word arrays as tagged with @split
- [much work:] more support for (64tass) SEGMENTS ?
- (What, how, isn't current BSS support enough?)
- Add a mechanism to allocate variables into golden ram (or segments really) (see GoldenRam class)
- maybe treat block "golden" in a special way: can only contain vars, every var will be allocated in the Golden ram area?
- maybe or may not needed: the variables can NOT have initialization values, they will all be set to zero on startup (simple memset)
just initialize them yourself in start() if you need a non-zero value .
- OR.... do all this automatically if 'golden' is enabled as a compiler option? So compiler allocates in ZP first, then Golden Ram, then regular ram
- OR.... make all this more generic and use some %segment option to create real segments for 64tass?
- (need separate step in codegen and IR to write the "golden" variables)
Need help with
@ -39,7 +30,15 @@ Need help with
Future Things and Ideas
^^^^^^^^^^^^^^^^^^^^^^^
Compiler:
- [much work:] more support for (64tass) SEGMENTS ?
- (What, how, isn't current BSS support enough?)
- Add a mechanism to allocate variables into golden ram (or segments really) (see GoldenRam class)
- maybe treat block "golden" in a special way: can only contain vars, every var will be allocated in the Golden ram area?
- maybe or may not needed: the variables can NOT have initialization values, they will all be set to zero on startup (simple memset)
just initialize them yourself in start() if you need a non-zero value .
- OR.... do all this automatically if 'golden' is enabled as a compiler option? So compiler allocates in ZP first, then Golden Ram, then regular ram
- OR.... make all this more generic and use some %segment option to create real segments for 64tass?
- (need separate step in codegen and IR to write the "golden" variables)
- ir: idea: (but LLVM IR simply keeps the variables, so not a good idea then?...): replace all scalar variables by an allocated register. Keep a table of the variable to register mapping (including the datatype)
global initialization values are simply a list of LOAD instructions.
Variables replaced include all subroutine parameters! So the only variables that remain as variables are arrays and strings.

View File

@ -1,4 +1,5 @@
%import textio
%option splitarrays
main {
sub start() {
@ -6,6 +7,8 @@ main {
str name2 = "name2"
uword[] names = [name1, name2, "name3"]
cx16.r0++
ubyte xx = 2
names[xx] = "irmen"
uword ww
for ww in names {
txt.print(ww)
@ -20,9 +23,8 @@ main {
}
txt.nl()
txt.print("end.")
%asm {{
lda #$3e
}}
repeat {
}
}
}