There's not much that can be done about this. We'll just have to issue warnings if someone codes such an instruction in a program that indicates multi-tasking may be enabled.
I hope to automate the following with metered exchanges:
pins <--> hub
pins <--> AUX
hub <--> AUX
Is there any possibility of mapping more than one 8*Long block into Cog?
The current WIDE (8 longs) are built from flipflops, so it's big. I would only do multiple blocks if we made our own memory to make this more space efficient. There's no time for that now.
There's not much that can be done about this. We'll just have to issue warnings if someone codes such an instruction in a program that indicates multi-tasking may be enabled.
I hope to automate the following with metered exchanges:
pins <--> hub
pins <--> AUX
hub <--> AUX
Great news!
Is there any possibility of mapping more than one 8*Long block into Cog?
The current WIDE (8 longs) are built from flipflops, so it's big. I would only do multiple blocks if we made our own memory to make this more space efficient. There's no time for that now.
OK. I wonder if we have HUBEXEC whether this will be required any more?
Would it be easy or difficult to have a mode where if cog operand addresses resolved to $0XX it referred to AUX and $1FF it referred to COG?
I am thinking of being able to use AUX as additional variable space (eg 256 longs in cog and 256 longs in hub), and usable by most/all instructions.
Instruction modification and other caveats might apply too. So just a simple/difficult answer is fine.
I think I understand what Bill and David were discussion regarding effectively executing from HUB without LMM. There are a couple of posts here that I think explains it better with code http://forums.parallax.com/showthrea...=1#post1224716
There's not much that can be done about this. We'll just have to issue warnings if someone codes such an instruction in a program that indicates multi-tasking may be enabled.
No worries Chip.
We will put that in the "Don't do this" section of the documentation!
Comments
There's not much that can be done about this. We'll just have to issue warnings if someone codes such an instruction in a program that indicates multi-tasking may be enabled.
I don't know if I'll do this. If I did, I probably wouldn't tell anybody except the few who would really want to know.
I don't think I'll pursue this because it would entail the same complexity as INDA/INDB do.
Because this involves science, and not just Verilog, there is probably no time to attempt it, for now.
I hope to automate the following with metered exchanges:
pins <--> hub
pins <--> AUX
hub <--> AUX
The current WIDE (8 longs) are built from flipflops, so it's big. I would only do multiple blocks if we made our own memory to make this more space efficient. There's no time for that now.
These all relate to hub execution and I have yet to explore exactly how this is going to work. I think it can be made to work, though.
Please do. But in this case it could be simpler. And it's not a priority.
Both OK.
Great news!
OK. I wonder if we have HUBEXEC whether this will be required any more?
Would it be easy or difficult to have a mode where if cog operand addresses resolved to $0XX it referred to AUX and $1FF it referred to COG?
I am thinking of being able to use AUX as additional variable space (eg 256 longs in cog and 256 longs in hub), and usable by most/all instructions.
Instruction modification and other caveats might apply too. So just a simple/difficult answer is fine.
Great news,
Thanks Chip.
No worries Chip.
We will put that in the "Don't do this" section of the documentation!