[SOLVED] Using SETINDx with REPS, a little gotcha.
ozpropdev
Posts: 2,791
Edit: OOPS!
TEST1 code is correct and does work properly.
Problem was caused by poor programming on my part.
Hi All
I recently upgraded to the latest FPGA build and got caught out trying to get it going.
I had some new code to trial, and being coded for the new FPGA I could not verify the code on old FPGA builds.
After a long night I found the problem had nothing to do with any of the new stuff but was caused by a very small "gotcha".
Here is the small code snippet and the solutions.
Not complicated code, but it caused BIG drama. I'm better now!
Cheers
Brian
TEST1 code is correct and does work properly.
Problem was caused by poor programming on my part.
Hi All
I recently upgraded to the latest FPGA build and got caught out trying to get it going.
I had some new code to trial, and being coded for the new FPGA I could not verify the code on old FPGA builds.
After a long night I found the problem had nothing to do with any of the new stuff but was caused by a very small "gotcha".
Here is the small code snippet and the solutions.
test1 reps #8,#1 '[s]FAILS[/s] WORKS setinda #qx pushx inda++ test2 setinda #qx 'WORKS reps #8,#1 nop pushx inda++ test3 reps #8,#2 'WORKS setinda #qx nop pushx inda++
Not complicated code, but it caused BIG drama. I'm better now!
Cheers
Brian
Comments
To my mind, the REPS/REPD opcode use in Assembler need to expand a little to
allow the Assembler to give what you intend.
ie if spacer instructions are dictated, they should be added by the assembler, if the user does not provide them.
I think spacer instructions also moves about with REPx variant, and task slicing, making automated support even more important.
If there are additional context issues, the assembler should warn or fix those too.
Thus your example becomes something like this
Any Lines between REPS and Reps_Start are 'execute before loop', and are free for the asm to use as the spacer, if legal.
If there are no lines offered, or the line is illegal (your case?) the ASM inserts NOPs as needed.
If the user flips to/from multi tasking, the code adjusts if needed.
The block reach no longer needs to be user-provided, it is easily ASM derived from the block start/end, allowing safer edits with no gotchas.
Code is more readable too.
As per usual, the .LST file always shows what the final code actually was.
Where that gets tricky is the assembler needs to know if your multi-tasking or not as REPx can only be used in single task mode.
That's not quite what I read into this part of the DOCs ?
* 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).
It does suggest tasking matters, so yes, ASM does need to 'know' that.
? Discussions on improving ASM prevents no one from testing. Test away...
What I really meant was based on this statement from some older DOCS.
"There is only one REPS/REPD circuit, so REPS/REPD's cannot be nested"
I assumed this also means that only 1 task can use REPx at a time.
I will try this later...
For me it looks more like you now need to wait one cycle after setting the INDx before you can use it.
Andy
You can have both.
If the editor is that aware, then your code gives the Assembler nothing to do.
Even with any special editor highlight, you really need some physical code check, to confirm you have met the rules.
Structures that help users avoid the fine print, can only help.
The suggested block support does more than one thing : besides now letting the assembler do that check (and you can easily disable any fix, or require a no-fix-reports build), it also auto-handles the block size - no tedious, silly (re) counting of lines of code.
The Opcode supports up to 64 line blocks - fancy (re)counting those every time you edit ?
A user may decide to use their own local labels, but if that is going to be common, why not make the ASM that little bit smarter ?.
As long as it's opt-in. The assembler default should be dumb.
test1 reps #8 setinda #qx 'suggested packer(s), ASM can swap as needed, or use NOPs Reps_Start pushx inda++ Reps_EndPlease don't add such block support to the assembler.I don't want my assembler code to start looking like some failed high level language.
I certainly don't want it rewriting code for me.
+1
The problem I have with making it smarter is at some point that smarts will require actually parsing the code and assembly language programmers who do tricks for whatever reason will have to add a layer of hassle to it all to account for the smart assembler that isn't quite as smart about whatever it is as they are. Meaning it gets written with less precision just so the assembler, wanna be compiler, does it's thing incorrectly to generate the desired result. Or worse, there are a bunch of "don't do it here, but please do it here and maybe do it over here, if it's not done there" kinds of things required to get the desired result.
Much better to simply write the desired result, and have it assembled into the desired binary.
IMHO, the better and more effective way to accomplish this goal is to employ a macro assembler where such constructs can be handled by the programmer with all behavior known and documented, not inferred by looking through some debug listing to find out what the assembler, wanna be compiler, actually did as opposed to what was written.
Also IMHO, either writing or adding Propeller support to an existing macro assembler might not be a bad project. Now that we've got HUBEXEC, very large assembly language programs make sense, as does the macro assembler approach now.
I really like the way our current assembler works. Frankly, it's really smart about data input, constants, can incorporate SPIN, etc... Beautiful. It's smart where it needs to be and those smarts add a lot of value. When I mean dumb, I mean in the sense of parsing code and making universal type assumptions that really aren't universally a value add. The few we will be making, such as "##" will make sense so much of the time it's worth it.
Going beyond that will require exceptions and exceptions then require pragmas, directives and other things needed to manage the cases where the well meaning assumptions aren't adding value and all of that makes the whole affair thick, as in more difficult, without actually adding a lot of value overall. Net loss. We don't need that.
Of course it is, but the P2 has gone way beyound that, with all sorts of context rules.
Then you choose lower productivity, where the programmer knows what he meant, but finds the "all behavior known and documented" has a lot more fishhooks than he expected, (even experienced programmers have saturation)
Where a mode change breaks code he thought was working ?
Now, instead of a listing showing what the chip does, when it does not work as expected, you have to fire up a debugger and work backwards. Only there is no Cycle-aware debugger and no cycle aware simulator yet.
So adoption of the device is slower than it could have been.
As I already mentioned, if you really, really want control over every byte, simply write your code in a way that produces a Zero fixes report. It becomes an entirely optional feature.
I would rather have the PC do the tedious low level checks for me, than find out the hard way.
Assemblers are adding NOPs already.
You can choose not to use that capability. The programmer still has total choice and control.
The asm does not re-write code, it takes the lines you gave it, and inserts NOPS if it needs to.
This low level 'automation' is not unusual in Assemblers, it helps productivity rather than harms it.
If you are averse to any blocking, then you are saying you will be manually counting lines in REPS blocks, and editing in two places ?
Surely no one has the time to be manually counting lines these days ?
As for Editing in two places, that's something tutors try to get students to avoid, because it will bite you.
Is everyone really going to keep a photocopy of all the instances of this in their head ? (and know exactly what it means, when)
* 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).
Answer: Nope.
No. That is what a macro assembler is for. Those cases and desired solutions get worked out in advance, then used for productivity. Anyone wondering how the binary got created can examine all of that and understand what decisions were made. Code is documentation. All behavior is known, not inferred.
That is what assembly language is. If you want to go above that, you aren't really doing assembly language, but something else instead. This is not bad, but it's not assembly language. Again, a macro assembler can address this nicely as can optional tools. But the core, reference assembler needs to be an assembler, not a compiler of sorts.
I would rather understand the chip. From there, we don't have as many checks. Assembly language is tedious. That is the nature of it. Moving above that is a fine objective, and there are lots of ways to do that. C comes to mind here, as does the already mentioned macro assembler, and guess what? GCC has a perfectly fine, and as I understand it, standard one too! That's the place for this kind of thing.
Isn't that what labels are for?
Yes, Very Large ASM programs are going to need better tools support.
Macro assembler is already in GCC tools, and yes, it is going to be essential for P2 work.
So would something like the following work?
In other words, use the "relative" operator. This won't help for tasks, but it would at least ease maintenance (no need to count instructions) and improve self-documentation (very obvious where the end of the block is).
The assembler we have with SPIN support is going to surprise you in how it will work for large projects.
That said, I've maintained from early on the GCC tools need to be awesome on P2, and this is one of the reasons. "Standard" macro assembler support is a big win for those who want to go down that path, mixing C into the mix, much as those of us will mix SPIN with PASM.
Many of my comments related to the assembler are in that context. It's not just "an assembler" in the sense many are used to. It's actually SPIN + PASM, and how that unified environment works together as well as it's relative complexity is a very important pillar of why Propellers are as productive as they are and I really don't want to see that broken.
"Standard" type approaches are fine! I understand the desire for them and the need. So let's do those in the standard tools and let's not pollute SPIN + PASM with things that really aren't going to add a lot of value. You may question that value jmg, and I get that. But those of us who do a lot of SPIN + PASM programming do not question it. Chip has some ways of doing things that aren't standard, but are lean, potent and productive and those need to exist.
Just as more standard approaches do. And it's best to do that in the respective domains, not mixing things for the best overall value for everybody involved.
Yes, my thoughts exactly. (And I need to get my FPGA booted this weekend, so I've not assembled that, but it's what I was thinking myself.)
And tasks are going to require various edits anyway. Task code will vary from non task code, and that's just something people need to work through, or again, generate macros for whatever cases they see as necessary.
In your code snippet: You are suggesting, in the comments, that the assembler can swap something or other for something or other else. depending in how that code sequece is used. I think we are all against this rewriting of our code.
Assuming now that is not the intention, that leaves the idea of having warnings or errors generated according to whether the code satisfies those rules you quote or not.
The question then is how does the assembler know if that code sequence is used in a multi-threaded program or not? I for sure cannot tell just by looking at it.
So the next thing you need is a construct to indicate if that sequence is used in a threaded program or not.
And what if it is used in both?
It just gets worse and worse.
Yes, that is exactly my point.
If you are going to manually insert two labels (careful now, you have just created a BLOCK ).
Voila, now you have the tag points in place, to check your asm, but your wish is to NOT make use of them any further.
That's totally fine, but allow someone who does want to have checks, have an assembler able to do so.
My point is to take what you would have already done as labels, and allow the ASM to check that it will operate as you expect.
You can disable such checking anytime you want.
I would like to see an example of how a macro assembler can do that checking for me.
The macro assemblers I use are clever, but they are simply not that context aware.
I write shiploads of Assembler, so I am all for getting all the help I can. This whole thread shows why that matters.
Perhaps you could contribute context aware checking tools?
Secondly, the whole point of using macros is to work out those cases and then quickly and conditionally produce them.
The core difference here is having a tool make assumptions to avoid lots of painful debugging, etc... as opposed to thinking through those cases, eliminating assumptions, and then avoid painful debugging, etc...
As the tool stands right now, it doesn't favor either case. A macro assembler would favor the latter case, and you want the tool to parse things to favor the former case.
Given we have the GCC tools there, again maybe you could contribute toward the case you favor?
...and the reference assembler stays the reference assembler. And thus: --as Heater says. I am in complete agreement. I really don't want the assembler doing things based on what it thinks I'm doing.
You've not met that burden at all.
What tools and CPU are you writing with and for? I'm just curious to learn more about where your perspective comes from. And what does the assembly language do?
The purist in me does not like inserting nops, when another line of code could have been used.
To use more words:
ie IF the line of code above Reps_Start can safely be inserted after Reps_Start instead of a NOP, THEN do so, and save the NOP.
The code is the same, and you have saved a NOP.
If that rule is too complex for some, you could have a lower choice of
ie IF REPS - Reps_Start needs a NOP, THEN insert Spacer instructions as required
This is simpler (but less compact that it could be), and there are assemblers that do NOP insertion.
I thought you were claiming a macro assembler was all that is needed ?
Do you have an example of how to do what I propose, using just a macro assembler ?
What's the current assembler written in? Maybe Chip could expose the guts (tokenizer, lexer, etc) so that others could write lint-like tools using the same core code. Frankly, even in a case like the code I suggested (using the relative operator), such a tool would come in handy when it detects task usage (which would warn about the "minus one" part).
Nicely put.
Guess which path takes less time, and is far more novice friendly ?
I would choose the better tool every time, and I would not call them assumptions, they are clear and explicit decisions.
That's all tools can do.
If you want something called a reference assembler, fine, freeze and archive any build you like.
The assemblers I work with/on, have new features being added that help productivity, even in 2013/2014.
Again, it's the difference in approach. I would use macros and some variables to setup the various block cases and then use them where I see them make sense. At no time would the assembler be making any decisions for me. I would simply have made those decisions, constructed useful blocks, and then call them as macros when needed. That, coupled with labels and expressions gets most of the hard work done.
For a final optimization path, like say replacing a nop with a useful instruction (a thing I think we all agree on) that comes after things are up and running. Then it gets tuned for best case speed / size.
Again, what assemblers and CPU? Come on. You've not ever answered a single question. Why not? I'm not looking for anything other than understanding as to where and why you come at this the way you do. Who knows? That discussion may well be productive. It won't be for sure this way.
BTW: The reference tools, in this context, are the ones Chip is going to produce. From there, derivatives will be produced.
I don't know if you are aware, but the goal here will be to produce a P2 chip complete with tools, including SPIN, monitor, loader, encryption, assembler, etc... Once that's done, it's done. If there is a serious bug in the tools, they will see an update, but if there isn't, they are done. And that's the reference design. The chip is done, the core tools needed for it are done.
Then we can think about P3, or other P2 variations!
Derivatives can advance from there however they need / want to. If Chip or others decide to move development on chip, like say translating the x86 assembler into PASM, we could close the loop and call the whole works "done" and then focus on other things. And now on P1 we have various open efforts that do this and that, but throughout all of that SPIN + PASM just is what it is. And that means a very large body of code works as it did on day one, with small exceptions here and there, such as that @@@ operator seen in another tool, such as BST.
At a higher level, away from SPIN + PASM, all sorts of things make sense, and so that is where they should be done, and I think that is a core difference in overall approach from what many may be used to where things rev all the time. SPIN + PASM doesn't need to rev all the time. I would argue that it shouldn't.
Other things can, should, and will. Which is precisely why I asked whether or not you were considering contributing context aware tools. You too could build on the core design and add them. Whether or not that continues to make sense would be a matter of user adoption at that point.
Novices aren't going to be writing much PASM. And you sure don't want them just writing stuff and having it happen for them "magically", right? That's voodoo. Precisely the thing we avoid in assembly language.
And frankly, I've taught assembly language to a fair number of people. Understanding the chip and being able to think through code well in advance of writing it is the single most important thing novices need to know.
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. Again, we differ on this, and it's OK. But those differences ripple through various ideas and processes in various ways.
Now, you want to really get the novice going?
Have them write SPIN. They get good at it. They could also write C and get good at it.
Then, start with PASM snippets. In SPIN 2, we are going to be able to drop those right into a program, and they start there. This little bit, that little bit, and soon they are writing whole functions. When exploring cool hardware features, they work in snippets and keep all the difficult things out of the picture, leaving just the very core problem of making the hardware go in specific ways.
With C, they can inline, etc... and do the same thing.
As they advance, they can transition to complete assembly language programs, if they so desire. Many of them won't need to, nor want to, and that's fine. And BTW, if they go there, a set of well realized macros can then offer up the basic framework for program management, flow, templates where a person can populate those things quickly, consistently and get back down to the little bit that really matters. They could go and use GAS for that, for example.
The other thing one gets from that is being able to drill down to the important bit that matters and think about it first. Bill has demonstrated that many times here, posting up core VM snippets or kernels of various kinds. I'll likely do similar kinds of things with video related bits. Get the kernel thought through, it's core cases done, then work out to the higher level of detail to where PASM quits making sense and then author the program in detail. Take that approach and there won't be anywhere near the level of debugging one finds when just authoring a program serially.
Taking this path is the primary reason many of us want / need in-line code to be dead simple along with the assembler being the same. It's the perfect transition into assembly language land. Much harder to break it out into a separate domain. Doesn't need to happen.
Clearly, not everyone is going to agree to a single solution. The first solution depends on Chip adding features to his assembler, which I think we can all agree is not where the focus needs to be right now. However, solutions two and three can be accomplished by the community at any time, and they can be used (or not) by anyone who wants to.
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.
Completely agreed.
BTW: On P1, the tool was x86 assembly language. Given the look of Pnut.exe, I'll bet it's still x86 assembly language.