Having a tool think through it for them means they really don't have to understand the chip as well, and that causes problems later on.
Better to know what it's doing. Exactly. That's the point of assembly language.
I see the point of Assembly Language as having control.
I am more than happy to NOT have to remember every fish-hook, I prefer to focus on writing lines of ASM, not also mentally remembering all of these pipeline caveats.
Here is just one, straight from the docs, to remind everyone of the details :
* Spacer instructions are required in 1-task applications to allow the pipeline to prime
before repeating can commence. If REPS is used by a task that uses no more than every 2nd
time slot, no spacers are needed. If REPD is used by a task that uses no more than every
4th time slot, no spacers are needed, as three intervening instructions will be provided
by the other task(s).
That housekeeping / rules stuff, is a task for a tool.
The P2 is complex, relax, and let the tools help. That's exactly what tools are for.
Worse, NOT doing this makes code less user portable, and revisions that much more dangerous.
I find I spend a lot of time trying to take the operator out of the build equation, choosing to design a system to be highly dependent on 100% operator concentration and skill, is nothing but counter productive, and asking for long term trouble.
Better tools will come, it is smarter to get them as early as possible so the reference code base has higher quality.
This is obviously one of those discussions that will not arrive at a consensus.
I think we are closer than you imagine
The core difference here is having a tool make simple decisions assumptions to avoid lots of painful debugging, etc... as opposed to thinking through those cases, eliminating assumptions, and then avoid painful debugging, etc...
I agree with the above statement, with one minor change ( as tools do not/cannot make assumptions, they make decisions).
My preference is to allow users to have the choice of tools support. (the first path of that statement)
Others may prefer the second path, I would not prevent that right.
In the meantime, maybe we could focus the discussion on "best practices" with what we currently have. That's bound to be useful for novices and gurus alike.
Problem there is. if you suppress discussion on how/where better tools can help, how will better tools ever appear ?
I am always thinking how to better remove the 'operator error/operator variance' from designs.
P2 complexity and context cases, makes that a larger variable.
And what tools are you using again to accomplish those goals?
As for taking the operator... don't we call those people programmers? Yeah, I thought so too. Seems to me if you want generic assembly language, that's C. And it's C with some in-line bits here and there to maximize things overall.
Otherwise, you've got good assembly language programmers, not operators, who are going to build good programs. Many of us would say revisions are equally dangerous when we write code only to have the assembler produce some other code.
And this control bit you put here. Well, the features you are asking for are not trivial additions to the assembler, which doesn't need them at all. Once GAS is bootstrapped onto the Propeller 2, go and get it done there.
One more time, "And what tools are those exactly? And on what CPU are you using them on?"
That is relevant to the discussion here. And this is why:
Here we've got one Chip Gracey who is authoring a complete package. Chip, assembler, SPIN, encryption, loader, etc... Now let's compare and contrast this to your assembler and how it's developed and why. We also have a community building on that, producing derivative tools, and we've got Parallax involved in those derivative tools. This discussion is for the derivative tools, not the core, reference tools being built right now.
Oops! Can't do that comparison, because you've not really supplied anything to do that with. Is there a team working on that product? How many? Etc... For all I know, you could be talking about Itanium development with tens of people working on assemblers and compilers to maximize that chip performance in multi-processor scenarios numbering in the hundreds. (SGI does this exact case and would make a few of the arguments you would, but they aren't comparable to what we are doing here, are they? And on that note, Intel themselves couldn't get the performance that SGI team did out of Itanium, because that team cut it's teeth optimizing the Smile out of MIPS for 15 years or so.)
It's not enough to come here making the case that you need a very significant development to save your team time --a team you call operators mind you, when it's pretty clear the features you are asking for really aren't required to make effective programs in a productive way.
Not enough at all.
So it's clear what you are advocating for. What's not so clear is the basis you have for "standard", etc...
Now you are likely right about this: Better tools will come!
Absolutely. When can we expect this context aware assembler capable of turning operators into assembly language programmers? I think it's gonna be hot!
The current assembler is written in x86 assembler as far as I'm aware. As is the rest of the Spin language compiler as used in the Prop Tool.
As such there is not much hope of using it as a lexer/parser for any programming tools. Perhaps it could be done by some x86 assembler enthusiasts with a lot of time on their hands but it's not really a good idea what with not being cross-platform and all that. Chip has not open sourced it so it's not really an option anyway.
Normally we have high level languages and we have assemblers. Let's ignore in-line asm, as used in C, for a moment. However the way things are put together with the Prop Tool we see that Spin and PASM are one and the same language. Defined and built by that "reference" Prop Tool implementation.
I'm a bit disturbed by the idea of a "reference" implementation. Ideally Spin and PASM would be rigorously, and separately, defined in language specifications, including BNF and all that stuff. As you see for language like C, Pascal, JavaScript etc etc.
With such documents in hand we would not have to give people like Roy the unenviable task of reverse engineering Chips x86 implementation so as to create the opensource and cross platform version, openspin.
It's a bit surprising that Chip is building the P2 assembler again in x86 rather than growing the C/C++ code of Roy's openspin. Poor Roy has his work cut out again to reverse engineer that!
Still I can see how this goes, like JavaScript before it, the language and compiler come first worry about a standard later. (Which is why JS has so many wonky features in it by the way, they wanted to remove them for the standards process but by then it was too late).
Back in technical school, circa 1973, we were introduce to programming by means of learning BASIC and assembler at the same time. Admittedly it was not with a real assembler language but a nice synthetic architecture running on a simulator. It was something of a standard in education at the time "City Guilds 139". So unlike Potatohead I do see novices kicking of with both Spin and PASM. The P1 architecture and assembly language are so simple and elegant as to make this possible.
I am less able to see novices kicking off with P2 assembler it is a lot more complex. A subset perhaps. As such I see little need for the suggested "hand holding" of the development tools.
Ideally Spin and PASM would be rigorously, and separately, defined in language specifications, including BNF and all that stuff.
Agreed, and sans that activity, a reference implementation is what we've got, which is why I'm opposed to polluting it out of hand.
So unlike Potatohead I do see novices kicking of with both Spin and PASM. The P1 architecture and assembly language are so simple and elegant as to make this possible.
I don't think we disagree. I myself kicked off with both in short order. Many of us did. P2 is going to be a bit harder, but not too much harder, particularly given the in-line and or basic "put PASM in a COG" approach we've got down from P1.
Anyone notice that jmg's suggested automatic NOP insertion and/or timing violation warnings could probably be done in a hand full of lines of Perl or some such language prior to assembling the code. A sort of "lint" program as someone said.
Many of us would say revisions are equally dangerous when we write code only to have the assembler produce some other code.
You need to read what I write more carefully.
Assembler is about control
The Assembler does not arbitrarily "produce some other code", it always behaves in a predictable, decision based manner. It always reports what it does, and the programmer is always in control.
The tools add the housekeeping context check the operator/programmer/human too often forgets.
Tools are great at this stuff, humans less so.
We all multi-task, interruptions happen. Relax, and let the tools help.
A reminder again the point of this discussion, is to improve the tools, viz
* Spacer instructions are required in 1-task applications to allow the pipeline to prime
before repeating can commence. If REPS is used by a task that uses no more than every 2nd
time slot, no spacers are needed. If REPD is used by a task that uses no more than every
4th time slot, no spacers are needed, as three intervening instructions will be provided
by the other task(s).
I was poking a bit of snark your way. For example, the programmer is in control, until they aren't. What happens when those features do not perform to spec?
Look, I get it. I just don't think we need those things at the stage.
And what tools are you comparing to again? Surely you can mention a product name.
A reminder again. My question was: how does this assembler know that a code sequence, such as your example, is used in a multi or single threaded context? Or indeed possibly in both at different times?
Without that information the tool is not in any position to advise about and/or repair you code according to the rule book you are quoting.
That seems like it requires yet another language construct for the programmer to specify "multi-taskedness" of code blocks. Soon the tool is more complex to use than the problem it is trying to solve.
Edit: And how does this change with HUB exec anyway?
A reminder again. My question was: how does this assembler know that a code sequence, such as your example, is used in a multi or single threaded context? Or indeed possibly in both at different times?
Without that information the tool is not in any position to advise about and/or repair you code according to the rule book you are quoting.
Of course, tools need to know what modes you intend, and also the full set of silicon rules / context caveats .
Assembler directives and target-control specs are common. (Just like GCC has many build options now.)
The tool can even check you have mode-controls that match what you indicated.
All this is driven by the rules of the silicon : There will be many like this example
* Spacer instructions are required in 1-task applications to allow the pipeline to prime
before repeating can commence. If REPS is used by a task that uses no more than every 2nd
time slot, no spacers are needed. If REPD is used by a task that uses no more than every
4th time slot, no spacers are needed, as three intervening instructions will be provided
by the other task(s).
plus this REPS requires 1 spacer instruction, REPD requires 3 spacer instructions
There may be some safe. common ground that allows code to run in a multi or single threaded context? Or indeed possibly in both at different times?
That seems like it requires yet another language construct for the programmer to specify "multi-taskedness" of code blocks. Soon the tool is more complex to use than the problem it is trying to solve.
Hardly, the tool decisions are relatively simple. ASM directives are simple things.
Where it could get complex, (and you would be very glad to have the tools), is if there are some subtle combinations that are mutually exclusive.
Hopefully, even there, some pipeline Spacer solution exists after your manual code change intervention to fix the messages.
I checked the Blackfin, they somewhat sidestep the 'spacer' conundrum this way
["The zero- overhead loop setup instruction will initialize three registers,
which are Loop Top Register, Loop Bottom Register and
Loop Count Register, in a single instruction. "]
There, they have built my suggested Repd_Start, Repd_End effectively right into the opcode, and the path taken to get to that Loop Top Register does not have the same pipeline spacer need issues.
I see DSP tools also support delayed branch instructions handling, where again the pipeline gets into the mix of things.
The rest of that text is only a reminder to think about threads when thinking about spacers. (I think it could be worded better)
Or perhaps that's two rules, Anyway, the suggested helper already requires some syntax for marking out the critical code sequence that might need spacers and some syntax for informing the tool of the intention that this code is running in one thread or many threads or how many. Or perhaps from HUB.
That is two new "WTF is this?" features to have explained and get mastery of that are more complex than the issue being tackled.
2) It is in the nature of Prop programming that critical timing in drivers like video, serial comms etc is done by counting instructions. We don't have clocked I/O and such features like say the XMOS devices so this becomes essential.
As such having the assembler stuff NOPs into places where we have not counted them to be is a no-no.
3) I get the feeling there are other such rules you might like to tackle with such helpers. This might get out of hand.
This conversation reminds me of the Intel i860 RISC processor.
In that machine you could write instructions something like:
add ro, r1, r3
An integer addition of r0 and r1 with result in r3.
For floating point you could write say:
fmad r4, r5, r6
Multiply floating point r4 by r5 and add the result to r6.
So far so good.
To make things twice as fast you could do both of those at the same time!
add ro, r1, r3 ; fmad r4, r5, r6
Yes, that's right, you can write two instructions on the same line for parallel execution of integer and floating point ops.
Still not fast enough, to realize the maximum speed of that chip you had to get the pipelines going:
padd ro, r1, r3 ; pfmad r4, r5, r6
or something like that.
Here is the kicker: That pfmad instruction would kick off a multiply and accumulate of r4 and r4 into r6 but the result would not actually appear in r6 until three or four instructions later! So we have:
padd ro, r1, r3 ; pfmad r4, r5, r6 ; Starts multiply and accumulate to r6
psub rx, rx, rx ; pfdiv rx, rx, rx ; Some other instructions.
padd rx, rx, rx ; pfmul rx, rx, rx
padd ro, r1, r3 ; padd r6, r7, r8 ; Now we can use the result of that first instruction in r6
Pretty hairy right!
It get's worse, put that stuff into a loop and working out how to do anything becomes impossible.
Programmers could not figure it out hand crafting assembler. Compiler writers could not get the thing optimized. Intel itself did not know how to reach peak flops in an FFT. (Some one else worked it out later).
Needless to say performance was poor and the i890 failed.
I do hope the P2 is not suffering from this phenomena.
As such having the assembler stuff NOPs into places where we have not counted them to be is a no-no.
The NOPs are hardly a surprise, if you enable the feature, you expect the ASM to do the housekeeping.
Your code will work without any WTF's.
My personal preference is to have tools support me, but there is another way to handle this issue, and that is to add safe/better versions of the mnemonics (call them anything you like )
REPS_Safe Counts,End_Label ' ASM does the #i calc, and inserts spacer eg NOP or WAIT #1
REPD_Safe Counts,End_Label ' ASM does the #i calc, and inserts spacers eg WAIT #3
This code always works as expected.
if we borrow from the Blackfin ASM syntax (and these guy DO know what the are doing..)
["The zero- overhead loop setup instruction will initialize three registers, which are Loop Top Register, Loop Bottom Register and Loop Count Register, in a single instruction. "]
we could have this alternate advanced form, essentially now just a clone of Blackfin syntax
REPS_Guru Counts,Start_Label,End_Label ' ASM does the #i calc, and can warn if Start_Label <> $+1
REPD_Guru : Counts,Start_Label,End_Label ' ASM does the #i calc, and can warn if Start_Label <> $+3
In all cases the P2 Binary opcodes are completely unchanged, only the ASM mnemonic handling has become less context dependent and clearer.
The ASM here is not doing anything 99% of ASMs can manage.
of course, the Guru, who will know when they have met this " If REPD is used by a task that uses no more than every 4th time slot, no spacers are needed ", & can disable the warnings.
A simple Assembler Error directive would help here, so you can locally 'sign off' with comments on why you are sure this is ok.
That also warns anyone else using the code.
The more common expert cases, do not even need warnings disabled, they will not give a warning, when correct.
Hi All
I thought I would inject my spin on this whole assembler thing, pardon the pun.
I will attempt to explain how this thread started and what REALLY caused the problem in the first place.
Basically I had some PASM code running 2 threads on 1 Cog.
I decided to split the code and run it in 2 Cogs. I split the code into 2 parts with there own ORG statement
and removed the multi-tasking related code.
All registers were moved to their respective "owners". All good so far.
Where I made a SILLY mistake was one (and only 1) register was being referenced by both Cogs.
So only cog1 was correctly addressing the register.
Where I started taking a "wrong turn" in my debigging was changing code in cog1 (test1 to 3) actually
was changing the address of the "real" register. This chamged Cog2's reference as well which gave weird results.
The Assembler did not error because the reference was to a valid label,so no problem in Pnut's eyes.
The assembler has no way of knowing of this being a "dual or crossed" reference.
Is this the assemblers falult or mine? I would suggest it's my fault.
So the code that seemed to work was simply "lucky" it offset the address to another one that did work.
Once a new register was defined for Cog2 it all worked perfectly.
What you describe has happened to people on the P1 as well. It happens when people have PASM in a single Spin object that contains code that is to be started in two COGs. The assembler can see all the DAT labels at compile time so it is happy, but they don't have the right addresses when load and run in their COGs.
Then you find out why you need ORG...and declare what looks like the same variable twice with different names.
jmg,
Your latest syntax starts to look better. I'm sure this sort of thing can be done with a simple preprocessor step.
I don't think that the Assembler can know if a REPS needs a spacer instruction or not.
An Assembler directive for that would need a lot of parameters like:
- Multitasking active or not
- Which task
- Task-scheduler list
all these matters.
The problem is that you can change the task-scheduler list at runtime, or you can run the REPS code part¨in more than one task. There are even cases where the same task sometimes need a spacer and sometimes not, depending on the current position in the task-scheduler. (for example: settask #%%1100)
So the SAFE rule is:
-Don't use REPS/REPD in code with tasks, replace them for example with DJNZ
-Don't use delayed jumps in code with tasks
And the really safe rule is "Don't use REPS/REPD".
One day you are going to change the run time environment of your code or copy and paste such a snippet from one place to another and then spend hours wondering why nothing works!
Sounds like instructions that could do with removing, they seriously violate the "principle of least surprise", problem solved
And the really safe rule is "Don't use REPS/REPD".
One day you are going to change the run time environment of your code or copy and paste such a snippet from one place to another and then spend hours wondering why nothing works!
I have given a safe version above, that does not need this huge sidestep.
It still allows the opcode, and handles uncertain cases by always including the spacer, invisible to the user.
Very simple.
Sounds like instructions that could do with removing, they seriously violate the "principle of least surprise", problem solved
Wow, remove a very useful opcode, rather than make a smarter mnemonic sounds a strange 'answer' to me ??
There is nothing wrong with the opcode, it has very useful instances, it is just the Assembler mnemonic/handling of the binary opcode which can be (easily) improved.
It still allows the opcode, and handles uncertain cases by always including the spacer, invisible to the user.
I'm a bit dense. How do you answer Ariba's concerns, and mine, that requiring spacers or not is a run time dependent thing? The assembler cannot know at compile time what is going to be the situation.
I was a bit tongue in cheek suggesting removal of those instructions. It's a follow on from Ariba's suggestion that the safest way to use them is not to use them!
jmg,
I'm a bit dense. How do you answer Ariba's concerns, and mine, that requiring spacers or not is a run time dependent thing? The assembler cannot know at compile time what is going to be the situation.
I was a bit tongue in cheek suggesting removal of those instructions. It's a follow on from Ariba's suggestion that the safest way to use them is not to use them!
This underlines why a better assembler mnemonic is needed.
Taking the docs
REPS and REPD are used to initiate block repeats. These instructions specify how many times the
trailing instruction block will be executed and how many instructions are in the block:
REPS differs from REPD by executing at the 2nd stage of the pipeline, instead of the 4th. By
executing two stages earlier, it needs only one spacer instruction *. Because of its earliness,
no conditional execution is possible, so it is forced to always execute, allowing the CCCC bits
to be repurposed, affording a contiguous 16-bit constant for the repeat count.
* Spacer instructions are required in 1-task applications to allow the pipeline to prime
before repeating can commence. If REPS is used by a task that uses no more than every 2nd
time slot, no spacers are needed. If REPD is used by a task that uses no more than every
4th time slot, no spacers are needed, as three intervening instructions will be provided
by the other task(s).
I take that as saying the spacer is a delay-fix-up, for the pipeline, and is optional when the delay may already be there.
It also means, if you insert a spacer, there is no optional dependency, and the code can always run as expected.
The first mnemonic above does that, and it gives a simple, robust, but less than smallest answer, which is why the second mnemonic form exists.
It's for those cases, where you really do want to wring the last bytes of code and have not only lowest loop times, but also use the 'slack' times as well, those cases will be quite rare, but they will be there.
In this case the ASM only checks for correct offsets to the labels, and even that can be disabled for those even rarer cases where the (guru) user knows the other delays are doing it for him.
ASM changes needed for the better mnemonics are not hard, within even an ASM coded in x86.
That's not what I am experiencing in reality.
I am currently working on a multi-tasking program that uses REPS. The REPS instruction will not work if I leave the spacer instruction in.
hmm.. Can you clarify 'not work' - does it execute the spacer opcode as well, or shift the whole block one earlier, or not work at all (never execute, not even once ?)
The docs say If REPS is used by a task that uses no more than every 2nd time slot, no spacers are needed.
Suggests to me it still works, (in some manner) but is less clear on the phase - it does not say if a spacer that is there is handled the same, (ie the fetch-order is still equal) or if the (virtual) task spacer becomes like a cycle, and is counted in the loop manager, which would move the phase and may even affect the counts ?
I can see the interactions get a little hairy, but if it was coded so the REPS state engine only started when PC=$+1, then I think it would tolerate any feed/task delays, and also properly skip the spacer, and then loop from there ?
hmm.. Can you clarify 'not work' - does it execute the spacer opcode as well, or shift the whole block one earlier, or not work at all (never execute, not even once ?)
The docs say If REPS is used by a task that uses no more than every 2nd time slot, no spacers are needed.
Suggests to me it still works, (in some manner) but is less clear on the phase - it does not say if a spacer that is there is handled the same, (ie the fetch-order is still equal) or if the (virtual) task spacer becomes like a cycle, and is counted in the loop manager, which would move the phase and may even affect the counts ?
I can see the interactions get a little hairy, but if it was coded so the REPS state engine only started when PC=$+1, then I think it would tolerate any feed/task delays, and also properly skip the spacer, and then loop from there ?
{ strange, did a post vanish ?}
@jmg
I removed the post almost straight away but you were too quick!
I am running some more tests to see what's going on?
Then I can give a more accurate account.
I'll keep you posted.
Brian
@jmg
I removed the post almost straight away but you were too quick!
I am running some more tests to see what's going on?
Then I can give a more accurate account.
I'll keep you posted.
Brian
I figured that was the case.... be interesting to see how it does interact.
With the spacer NOP myreg = $D670 %1101_0110_0111_0000 (3 shifts missing) (unstable)
With spacer removed myreg = $FACE %1111_1010_1100_1110 as expected. (stable)
With spacer instruction in place result intermittently flips between both outcomes?
Confirming this is code that meets ? If REPS is used by a task that uses no more than every 2nd time slot, no spacers are needed.
?intermittently flips? - at what flip rate ?
The 3 missing shifts would match the 'velocity' model rather than 'opcode' model.
( velocity means REPS actually starts after 1 clk, not one-opcode fetched)
ie the hidden tasking delay replaces the needed spacer, and now [NOP + 3 shifts] occur 4 time, plus one more at the end, on loop exit for 13 (3 less than 16) .
The 'Velocity' model does not quite explain intermittently flips - unless the time slots matter, as well.
What is the exact time slot pattern ? (Could 2 be adjacent ?)
Confirming this is code that meets ? If REPS is used by a task that uses no more than every 2nd time slot, no spacers are needed.
?intermittently flips? - at what flip rate ?
The 3 missing shifts would match the 'velocity' rather than 'opcode' model.
ie the hidden tasking delay replaces the needed spacer, and now [NOP + 3 shifts] occur 4 time, plus one more at the end, on loop exit for 13 (3 less than 16) .
The 'Velocity' model does not explain intermittently flips - unless the time slots matter, as well.
What is the exact time slot pattern ?
Here's my task schedule pattern. There was a typo which I corrected. Thanks
schedule long %%2100_1010_1010_1010 'intermittent (typo)
schedule long %%2010_1010_1010_1010 'stopped intermittent behavioyr
Spacer instruction still fails after typo correction, but intermittent result "flip" has ceased.
Comments
I see the point of Assembly Language as having control.
I am more than happy to NOT have to remember every fish-hook, I prefer to focus on writing lines of ASM, not also mentally remembering all of these pipeline caveats.
Here is just one, straight from the docs, to remind everyone of the details :
* Spacer instructions are required in 1-task applications to allow the pipeline to prime
before repeating can commence. If REPS is used by a task that uses no more than every 2nd
time slot, no spacers are needed. If REPD is used by a task that uses no more than every
4th time slot, no spacers are needed, as three intervening instructions will be provided
by the other task(s).
That housekeeping / rules stuff, is a task for a tool.
The P2 is complex, relax, and let the tools help. That's exactly what tools are for.
Worse, NOT doing this makes code less user portable, and revisions that much more dangerous.
I find I spend a lot of time trying to take the operator out of the build equation, choosing to design a system to be highly dependent on 100% operator concentration and skill, is nothing but counter productive, and asking for long term trouble.
Better tools will come, it is smarter to get them as early as possible so the reference code base has higher quality.
I think we are closer than you imagine
I agree with the above statement, with one minor change ( as tools do not/cannot make assumptions, they make decisions).
My preference is to allow users to have the choice of tools support. (the first path of that statement)
Others may prefer the second path, I would not prevent that right.
Problem there is. if you suppress discussion on how/where better tools can help, how will better tools ever appear ?
I am always thinking how to better remove the 'operator error/operator variance' from designs.
P2 complexity and context cases, makes that a larger variable.
As for taking the operator... don't we call those people programmers? Yeah, I thought so too. Seems to me if you want generic assembly language, that's C. And it's C with some in-line bits here and there to maximize things overall.
Otherwise, you've got good assembly language programmers, not operators, who are going to build good programs. Many of us would say revisions are equally dangerous when we write code only to have the assembler produce some other code.
And this control bit you put here. Well, the features you are asking for are not trivial additions to the assembler, which doesn't need them at all. Once GAS is bootstrapped onto the Propeller 2, go and get it done there.
One more time, "And what tools are those exactly? And on what CPU are you using them on?"
That is relevant to the discussion here. And this is why:
Here we've got one Chip Gracey who is authoring a complete package. Chip, assembler, SPIN, encryption, loader, etc... Now let's compare and contrast this to your assembler and how it's developed and why. We also have a community building on that, producing derivative tools, and we've got Parallax involved in those derivative tools. This discussion is for the derivative tools, not the core, reference tools being built right now.
Oops! Can't do that comparison, because you've not really supplied anything to do that with. Is there a team working on that product? How many? Etc... For all I know, you could be talking about Itanium development with tens of people working on assemblers and compilers to maximize that chip performance in multi-processor scenarios numbering in the hundreds. (SGI does this exact case and would make a few of the arguments you would, but they aren't comparable to what we are doing here, are they? And on that note, Intel themselves couldn't get the performance that SGI team did out of Itanium, because that team cut it's teeth optimizing the Smile out of MIPS for 15 years or so.)
It's not enough to come here making the case that you need a very significant development to save your team time --a team you call operators mind you, when it's pretty clear the features you are asking for really aren't required to make effective programs in a productive way.
Not enough at all.
So it's clear what you are advocating for. What's not so clear is the basis you have for "standard", etc...
Now you are likely right about this: Better tools will come!
Absolutely. When can we expect this context aware assembler capable of turning operators into assembly language programmers? I think it's gonna be hot!
As such there is not much hope of using it as a lexer/parser for any programming tools. Perhaps it could be done by some x86 assembler enthusiasts with a lot of time on their hands but it's not really a good idea what with not being cross-platform and all that. Chip has not open sourced it so it's not really an option anyway.
Normally we have high level languages and we have assemblers. Let's ignore in-line asm, as used in C, for a moment. However the way things are put together with the Prop Tool we see that Spin and PASM are one and the same language. Defined and built by that "reference" Prop Tool implementation.
I'm a bit disturbed by the idea of a "reference" implementation. Ideally Spin and PASM would be rigorously, and separately, defined in language specifications, including BNF and all that stuff. As you see for language like C, Pascal, JavaScript etc etc.
With such documents in hand we would not have to give people like Roy the unenviable task of reverse engineering Chips x86 implementation so as to create the opensource and cross platform version, openspin.
It's a bit surprising that Chip is building the P2 assembler again in x86 rather than growing the C/C++ code of Roy's openspin. Poor Roy has his work cut out again to reverse engineer that!
Still I can see how this goes, like JavaScript before it, the language and compiler come first worry about a standard later. (Which is why JS has so many wonky features in it by the way, they wanted to remove them for the standards process but by then it was too late).
Back in technical school, circa 1973, we were introduce to programming by means of learning BASIC and assembler at the same time. Admittedly it was not with a real assembler language but a nice synthetic architecture running on a simulator. It was something of a standard in education at the time "City Guilds 139". So unlike Potatohead I do see novices kicking of with both Spin and PASM. The P1 architecture and assembly language are so simple and elegant as to make this possible.
I am less able to see novices kicking off with P2 assembler it is a lot more complex. A subset perhaps. As such I see little need for the suggested "hand holding" of the development tools.
There we go, my random thoughts for the day
Agreed, and sans that activity, a reference implementation is what we've got, which is why I'm opposed to polluting it out of hand.
I don't think we disagree. I myself kicked off with both in short order. Many of us did. P2 is going to be a bit harder, but not too much harder, particularly given the in-line and or basic "put PASM in a COG" approach we've got down from P1.
You need to read what I write more carefully.
Assembler is about control
The Assembler does not arbitrarily "produce some other code", it always behaves in a predictable, decision based manner. It always reports what it does, and the programmer is always in control.
The tools add the housekeeping context check the operator/programmer/human too often forgets.
Tools are great at this stuff, humans less so.
We all multi-task, interruptions happen. Relax, and let the tools help.
A reminder again the point of this discussion, is to improve the tools, viz
* Spacer instructions are required in 1-task applications to allow the pipeline to prime
before repeating can commence. If REPS is used by a task that uses no more than every 2nd
time slot, no spacers are needed. If REPD is used by a task that uses no more than every
4th time slot, no spacers are needed, as three intervening instructions will be provided
by the other task(s).
Look, I get it. I just don't think we need those things at the stage.
And what tools are you comparing to again? Surely you can mention a product name.
A reminder again. My question was: how does this assembler know that a code sequence, such as your example, is used in a multi or single threaded context? Or indeed possibly in both at different times?
Without that information the tool is not in any position to advise about and/or repair you code according to the rule book you are quoting.
That seems like it requires yet another language construct for the programmer to specify "multi-taskedness" of code blocks. Soon the tool is more complex to use than the problem it is trying to solve.
Edit: And how does this change with HUB exec anyway?
Of course, tools need to know what modes you intend, and also the full set of silicon rules / context caveats .
Assembler directives and target-control specs are common. (Just like GCC has many build options now.)
The tool can even check you have mode-controls that match what you indicated.
All this is driven by the rules of the silicon : There will be many like this example
* Spacer instructions are required in 1-task applications to allow the pipeline to prime
before repeating can commence. If REPS is used by a task that uses no more than every 2nd
time slot, no spacers are needed. If REPD is used by a task that uses no more than every
4th time slot, no spacers are needed, as three intervening instructions will be provided
by the other task(s).
plus this
REPS requires 1 spacer instruction, REPD requires 3 spacer instructions
There may be some safe. common ground that allows code to run in a multi or single threaded context? Or indeed possibly in both at different times?
Hardly, the tool decisions are relatively simple. ASM directives are simple things.
Where it could get complex, (and you would be very glad to have the tools), is if there are some subtle combinations that are mutually exclusive.
Hopefully, even there, some pipeline Spacer solution exists after your manual code change intervention to fix the messages.
Good question.
There will be many caveats in P2, which is why I raise this whole idea.
Context variable execution pretty much demands automated checks.
I've seen other Assemblers/Linkers insert NOPs, so this is not a new problem, or even really a new assembler activity.
["The zero- overhead loop setup instruction will initialize three registers,
which are Loop Top Register, Loop Bottom Register and
Loop Count Register, in a single instruction. "]
There, they have built my suggested Repd_Start, Repd_End effectively right into the opcode, and the path taken to get to that Loop Top Register does not have the same pipeline spacer need issues.
I see DSP tools also support delayed branch instructions handling, where again the pipeline gets into the mix of things.
I do have sympathy for your request/idea, it's just that I have a couple of issues with it:
1) The rule we are discussing here is basically:
REPS requires 1 spacer instruction, REPD requires 3 spacer instructions
The rest of that text is only a reminder to think about threads when thinking about spacers. (I think it could be worded better)
Or perhaps that's two rules, Anyway, the suggested helper already requires some syntax for marking out the critical code sequence that might need spacers and some syntax for informing the tool of the intention that this code is running in one thread or many threads or how many. Or perhaps from HUB.
That is two new "WTF is this?" features to have explained and get mastery of that are more complex than the issue being tackled.
2) It is in the nature of Prop programming that critical timing in drivers like video, serial comms etc is done by counting instructions. We don't have clocked I/O and such features like say the XMOS devices so this becomes essential.
As such having the assembler stuff NOPs into places where we have not counted them to be is a no-no.
3) I get the feeling there are other such rules you might like to tackle with such helpers. This might get out of hand.
In that machine you could write instructions something like: An integer addition of r0 and r1 with result in r3.
For floating point you could write say: Multiply floating point r4 by r5 and add the result to r6.
So far so good.
To make things twice as fast you could do both of those at the same time! Yes, that's right, you can write two instructions on the same line for parallel execution of integer and floating point ops.
Still not fast enough, to realize the maximum speed of that chip you had to get the pipelines going: or something like that.
Here is the kicker: That pfmad instruction would kick off a multiply and accumulate of r4 and r4 into r6 but the result would not actually appear in r6 until three or four instructions later! So we have: Pretty hairy right!
It get's worse, put that stuff into a loop and working out how to do anything becomes impossible.
Programmers could not figure it out hand crafting assembler. Compiler writers could not get the thing optimized. Intel itself did not know how to reach peak flops in an FFT. (Some one else worked it out later).
Needless to say performance was poor and the i890 failed.
I do hope the P2 is not suffering from this phenomena.
That is part of what I am trying to avoid.
from earlier
The NOPs are hardly a surprise, if you enable the feature, you expect the ASM to do the housekeeping.
Your code will work without any WTF's.
My personal preference is to have tools support me, but there is another way to handle this issue, and that is to add safe/better versions of the mnemonics (call them anything you like )
REPS_Safe Counts,End_Label ' ASM does the #i calc, and inserts spacer eg NOP or WAIT #1
REPD_Safe Counts,End_Label ' ASM does the #i calc, and inserts spacers eg WAIT #3
This code always works as expected.
if we borrow from the Blackfin ASM syntax (and these guy DO know what the are doing..)
["The zero- overhead loop setup instruction will initialize three registers, which are Loop Top Register, Loop Bottom Register and Loop Count Register, in a single instruction. "]
we could have this alternate advanced form, essentially now just a clone of Blackfin syntax
REPS_Guru Counts,Start_Label,End_Label ' ASM does the #i calc, and can warn if Start_Label <> $+1
REPD_Guru : Counts,Start_Label,End_Label ' ASM does the #i calc, and can warn if Start_Label <> $+3
In all cases the P2 Binary opcodes are completely unchanged, only the ASM mnemonic handling has become less context dependent and clearer.
The ASM here is not doing anything 99% of ASMs can manage.
of course, the Guru, who will know when they have met this " If REPD is used by a task that uses no more than every 4th time slot, no spacers are needed ", & can disable the warnings.
A simple Assembler Error directive would help here, so you can locally 'sign off' with comments on why you are sure this is ok.
That also warns anyone else using the code.
The more common expert cases, do not even need warnings disabled, they will not give a warning, when correct.
I thought I would inject my spin on this whole assembler thing, pardon the pun.
I will attempt to explain how this thread started and what REALLY caused the problem in the first place.
Basically I had some PASM code running 2 threads on 1 Cog.
I decided to split the code and run it in 2 Cogs. I split the code into 2 parts with there own ORG statement
and removed the multi-tasking related code.
All registers were moved to their respective "owners". All good so far.
Where I made a SILLY mistake was one (and only 1) register was being referenced by both Cogs.
So only cog1 was correctly addressing the register.
Where I started taking a "wrong turn" in my debigging was changing code in cog1 (test1 to 3) actually
was changing the address of the "real" register. This chamged Cog2's reference as well which gave weird results.
The Assembler did not error because the reference was to a valid label,so no problem in Pnut's eyes.
The assembler has no way of knowing of this being a "dual or crossed" reference.
Is this the assemblers falult or mine? I would suggest it's my fault.
So the code that seemed to work was simply "lucky" it offset the address to another one that did work.
Once a new register was defined for Cog2 it all worked perfectly.
A silly mistake that had a dramatic effect.
Cheers
Brian
What you describe has happened to people on the P1 as well. It happens when people have PASM in a single Spin object that contains code that is to be started in two COGs. The assembler can see all the DAT labels at compile time so it is happy, but they don't have the right addresses when load and run in their COGs.
Then you find out why you need ORG...and declare what looks like the same variable twice with different names.
jmg,
Your latest syntax starts to look better. I'm sure this sort of thing can be done with a simple preprocessor step.
An Assembler directive for that would need a lot of parameters like:
- Multitasking active or not
- Which task
- Task-scheduler list
all these matters.
The problem is that you can change the task-scheduler list at runtime, or you can run the REPS code part¨in more than one task. There are even cases where the same task sometimes need a spacer and sometimes not, depending on the current position in the task-scheduler. (for example: settask #%%1100)
So the SAFE rule is:
-Don't use REPS/REPD in code with tasks, replace them for example with DJNZ
-Don't use delayed jumps in code with tasks
Andy
Brian
And the really safe rule is "Don't use REPS/REPD".
One day you are going to change the run time environment of your code or copy and paste such a snippet from one place to another and then spend hours wondering why nothing works!
Sounds like instructions that could do with removing, they seriously violate the "principle of least surprise", problem solved
I have given a safe version above, that does not need this huge sidestep.
It still allows the opcode, and handles uncertain cases by always including the spacer, invisible to the user.
Very simple.
Wow, remove a very useful opcode, rather than make a smarter mnemonic sounds a strange 'answer' to me ??
There is nothing wrong with the opcode, it has very useful instances, it is just the Assembler mnemonic/handling of the binary opcode which can be (easily) improved.
I'm a bit dense. How do you answer Ariba's concerns, and mine, that requiring spacers or not is a run time dependent thing? The assembler cannot know at compile time what is going to be the situation.
I was a bit tongue in cheek suggesting removal of those instructions. It's a follow on from Ariba's suggestion that the safest way to use them is not to use them!
This underlines why a better assembler mnemonic is needed.
Taking the docs
REPS and REPD are used to initiate block repeats. These instructions specify how many times the
trailing instruction block will be executed and how many instructions are in the block:
REPS #n,#i - execute 1..64 instructions 1..65536 times, requires 1 spacer instruction *
REPD #i - execute 1..64 instructions infinitely, requires 3 spacer instructions *
REPD D,#i - execute 1..64 instructions D+1 times, requires 3 spacer instructions *
REPD #n,#i - execute 1..64 instructions 1..512 times, requires 3 spacer instructions *
REPS differs from REPD by executing at the 2nd stage of the pipeline, instead of the 4th. By
executing two stages earlier, it needs only one spacer instruction *. Because of its earliness,
no conditional execution is possible, so it is forced to always execute, allowing the CCCC bits
to be repurposed, affording a contiguous 16-bit constant for the repeat count.
* Spacer instructions are required in 1-task applications to allow the pipeline to prime
before repeating can commence. If REPS is used by a task that uses no more than every 2nd
time slot, no spacers are needed. If REPD is used by a task that uses no more than every
4th time slot, no spacers are needed, as three intervening instructions will be provided
by the other task(s).
I take that as saying the spacer is a delay-fix-up, for the pipeline, and is optional when the delay may already be there.
It also means, if you insert a spacer, there is no optional dependency, and the code can always run as expected.
The first mnemonic above does that, and it gives a simple, robust, but less than smallest answer, which is why the second mnemonic form exists.
It's for those cases, where you really do want to wring the last bytes of code and have not only lowest loop times, but also use the 'slack' times as well, those cases will be quite rare, but they will be there.
In this case the ASM only checks for correct offsets to the labels, and even that can be disabled for those even rarer cases where the (guru) user knows the other delays are doing it for him.
ASM changes needed for the better mnemonics are not hard, within even an ASM coded in x86.
hmm.. Can you clarify 'not work' - does it execute the spacer opcode as well, or shift the whole block one earlier, or not work at all (never execute, not even once ?)
The docs say
If REPS is used by a task that uses no more than every 2nd time slot, no spacers are needed.
Suggests to me it still works, (in some manner) but is less clear on the phase - it does not say if a spacer that is there is handled the same, (ie the fetch-order is still equal) or if the (virtual) task spacer becomes like a cycle, and is counted in the loop manager, which would move the phase and may even affect the counts ?
I can see the interactions get a little hairy, but if it was coded so the REPS state engine only started when PC=$+1, then I think it would tolerate any feed/task delays, and also properly skip the spacer, and then loop from there ?
{ strange, did a post vanish ?}
@jmg
I removed the post almost straight away but you were too quick!
I am running some more tests to see what's going on?
Then I can give a more accurate account.
I'll keep you posted.
Brian
I figured that was the case.... be interesting to see how it does interact.
With the spacer NOP myreg = $D670 %1101_0110_0111_0000 (3 shifts missing) (unstable)
With spacer removed myreg = $FACE %1111_1010_1100_1110 as expected. (stable)
With spacer instruction in place result intermittently flips between both outcomes?
Brian
Confirming this is code that meets ?
If REPS is used by a task that uses no more than every 2nd time slot, no spacers are needed.
?intermittently flips? - at what flip rate ?
The 3 missing shifts would match the 'velocity' model rather than 'opcode' model.
( velocity means REPS actually starts after 1 clk, not one-opcode fetched)
ie the hidden tasking delay replaces the needed spacer, and now [NOP + 3 shifts] occur 4 time, plus one more at the end, on loop exit for 13 (3 less than 16) .
The 'Velocity' model does not quite explain intermittently flips - unless the time slots matter, as well.
What is the exact time slot pattern ? (Could 2 be adjacent ?)
Here's my task schedule pattern. There was a typo which I corrected. Thanks
Spacer instruction still fails after typo correction, but intermittent result "flip" has ceased.
Brian