I like this much better. My preference would be low memory for all of it, but this does differentiate the two and does allow for the contiguous space too. It does so without funky addressing or moving the COG from 0.
Cogs need to start at $00000 for a lot of human reasons, like register addresses being thoroughly $0-based, and because cogs are the fundamental organisms here. It needs to feel sensible to the user.
Jmg, I understand what you are saying, but ergonomic perceptions are critical in this whole thing. As long as people, and not just compilers, are going to be working with this architecture, it needs to be as uncomplicated as possible. LUT-after-cog makes most sense from this perpective.
Cogs need to start at $00000 for a lot of human reasons, like register addresses being thoroughly $0-based, and because cogs are the fundamental organisms here. It needs to feel sensible to the user.
Jmg, I understand what you are saying, but ergonomic perceptions are critical in this whole thing. As long as people, and not just compilers, are going to be working with this architecture, it needs to be as uncomplicated as possible. LUT-after-cog makes most sense from this perpective.
What about Roys variation of LUT wrap into COG at $0000 ?
What about having LUT addressing be mapped to the end of address space so that it wraps into cog space (which would stay starting at 0)?
That seems more acceptable to me...
That variation preserves the 'human reasons' of $0000 but nicely avoids the glaring break in the middle of code space, and so allows easier CODE management, allows larger subroutines and larger CASE tables.
It just requires that PC wraps on INC, and rel jumps, which I think is easy or even inherent ?
Cogs need to start at $00000 for a lot of human reasons, like register addresses being thoroughly $0-based, and because cogs are the fundamental organisms here. It needs to feel sensible to the user.
Jmg, I understand what you are saying, but ergonomic perceptions are critical in this whole thing. As long as people, and not just compilers, are going to be working with this architecture, it needs to be as uncomplicated as possible. LUT-after-cog makes most sense from this perpective.
What about Roys variation of LUT wrap into COG at $0000 ?
What about having LUT addressing be mapped to the end of address space so that it wraps into cog space (which would stay starting at 0)?
That seems more acceptable to me...
That variation preserves the 'human reasons' of $0000 but nicely avoids the glaring break in the middle of code space, and so allows easier CODE management, allows larger subroutines and larger CASE tables.
It just requires that PC wraps on INC, and rel jumps, which I think is easy or even inherent ?
Cogs need to start at $00000 for a lot of human reasons, like register addresses being thoroughly $0-based, and because cogs are the fundamental organisms here. It needs to feel sensible to the user.
Jmg, I understand what you are saying, but ergonomic perceptions are critical in this whole thing. As long as people, and not just compilers, are going to be working with this architecture, it needs to be as uncomplicated as possible. LUT-after-cog makes most sense from this perpective.
What about Roys variation of LUT wrap into COG at $0000 ?
What about having LUT addressing be mapped to the end of address space so that it wraps into cog space (which would stay starting at 0)?
That seems more acceptable to me...
That variation preserves the 'human reasons' of $0000 but nicely avoids the glaring break in the middle of code space, and so allows easier CODE management, allows larger subroutines and larger CASE tables.
It just requires that PC wraps on INC, and rel jumps, which I think is easy or even inherent ?
I don't know, Jmg. it's hard for me to get enthused about that.
This cog/lut wrapping possibility invokes more considerations about code and data placement than just having them separated does. A lot of this has to do with the fact that the assembler builds code upwards from a fixed address, rather than top-justifies it against an upper boundary, which would need to be done for variables, in order to have a 1k program begin in the lut. Even if I made the assembler handle that, it would look too crazy for beginners.
P.S. In order to make that work, we would need an assembler directive to advance the origin, if necessay, to get into cog space, in case we were still in lut space, so that register variable declarations could begin. It just seems a lot easier to keep cog and lut separate, so that you clearly set the contents of each. They must be loaded separately, anyway.
P.S. In order to make that work, we would need an assembler directive to advance the origin, if necessay, to get into cog space, in case we were still in lut space, so that register variable declarations could begin.
Yes, that's usually done with a Data segment, so you can for example, code in LUT, then declare a couple of variables in context and continue coding in LUT.
ASM collects the DS items (usually in order) and they are allocated into the relevant segment.
The MAP & LST files show where everything ended up.
Using segment statement keeps it clean, and users are not jumping about.
Instead of normal segment directives, how about named DAT blocks? All of the data in a collection of DAT blocks with the same name in the same file will be contiguous in hubram.
DAT a
long 0
DAT b
long 1
DAT a
long 2
DAT b
long 3
would result in all of a's contents appearing contiguously in the compiled image as "long 0, 2" and all of b's contents appearing contiguously as "long 1, 3". It might also be nice to be able to specify the relative order of blocks as well somehow.
That way, you can have DAT blocks named cogcode to hold cog code, lutcode to hold lut code, hubcode to hold hub code, strings to hold strings, etc. and be able to interleave the definitions.
Instead of normal segment directives, how about named DAT blocks?
....
That way, you can have DAT blocks named cogcode to hold cog code, lutcode to hold lut code, hubcode to hold hub code, strings to hold strings, etc. and be able to interleave the definitions.
Yes, that is pretty much the idea of Segments.
Usually you have Absolute and relocatable variants, and the Absolute ones are for things like SFR, Interrupt vectors and reset entry.
Relocatable ones collect items in like-named segments, and commonly they do intersperse with code.
This also makes mixing Assembler and HLL easier, as HLL use this approach in their code generation.
With the exception of the ABSOLUTE segments, users mostly do not care about tracking addresses to a fine degree.
However, with a hard-break, you will need extra warning messages for "LUT CODE exceded!!, please break Functions into smaller pieces, and move some into COG or HUB", that can be avoided with roll-over into COG.
Comments
Jmg, I understand what you are saying, but ergonomic perceptions are critical in this whole thing. As long as people, and not just compilers, are going to be working with this architecture, it needs to be as uncomplicated as possible. LUT-after-cog makes most sense from this perpective.
What about Roys variation of LUT wrap into COG at $0000 ?
That variation preserves the 'human reasons' of $0000 but nicely avoids the glaring break in the middle of code space, and so allows easier CODE management, allows larger subroutines and larger CASE tables.
It just requires that PC wraps on INC, and rel jumps, which I think is easy or even inherent ?
I don't know, Jmg. it's hard for me to get enthused about that.
This cog/lut wrapping possibility invokes more considerations about code and data placement than just having them separated does. A lot of this has to do with the fact that the assembler builds code upwards from a fixed address, rather than top-justifies it against an upper boundary, which would need to be done for variables, in order to have a 1k program begin in the lut. Even if I made the assembler handle that, it would look too crazy for beginners.
P.S. In order to make that work, we would need an assembler directive to advance the origin, if necessay, to get into cog space, in case we were still in lut space, so that register variable declarations could begin. It just seems a lot easier to keep cog and lut separate, so that you clearly set the contents of each. They must be loaded separately, anyway.
Yes, that's usually done with a Data segment, so you can for example, code in LUT, then declare a couple of variables in context and continue coding in LUT.
ASM collects the DS items (usually in order) and they are allocated into the relevant segment.
The MAP & LST files show where everything ended up.
Using segment statement keeps it clean, and users are not jumping about.
DAT a long 0 DAT b long 1 DAT a long 2 DAT b long 3would result in all of a's contents appearing contiguously in the compiled image as "long 0, 2" and all of b's contents appearing contiguously as "long 1, 3". It might also be nice to be able to specify the relative order of blocks as well somehow.That way, you can have DAT blocks named cogcode to hold cog code, lutcode to hold lut code, hubcode to hold hub code, strings to hold strings, etc. and be able to interleave the definitions.
Yes, that is pretty much the idea of Segments.
Usually you have Absolute and relocatable variants, and the Absolute ones are for things like SFR, Interrupt vectors and reset entry.
Relocatable ones collect items in like-named segments, and commonly they do intersperse with code.
This also makes mixing Assembler and HLL easier, as HLL use this approach in their code generation.
With the exception of the ABSOLUTE segments, users mostly do not care about tracking addresses to a fine degree.
However, with a hard-break, you will need extra warning messages for "LUT CODE exceded!!, please break Functions into smaller pieces, and move some into COG or HUB", that can be avoided with roll-over into COG.