Does seem like we could use an "align" compiler keyword.
Was just reading new fifo doc and it says data needs to be long aligned for looping. But, there's no way to tell compiler to make a table long aligned now, right?
A while back, I suggested the following:
BYTE/WORD/LONG : aligned data
PBYTE/PWORD/PLONG : packed data
This way, BYTE/WORD/LONG continue to work as everyone is already familiar with, while the P* variant provides explicit indication of intent.
One thing that is driving everyone nuts is the "@" operator. It was originally used to get the hub address of things. Then, it was used for relative branches. Now, it does both! Branches check for @ at the beginning of the address, and use it to compute relative offsets. If you use '@label' in a non-branch instruction, it means 'the absolute address of in hub memory'. What we need to do is differentiate these two cases of '@' so that one stays '@' and the other becomes some other character, like a back-tick or caret or something - anything else!
It is fast turning into spaghetti soup and hieroglyphs, and I thinks needs a proper cleanup pass.
Most common usage should be the cleanest, and human-readable trumps saving characters.
labels as destinations are the most common usage in ASM, so JMP Label
is the cleanest and very widely understood.
That leaves indirect needing a form JMP @ Register
JMP @ PC+Register 'JMPREL
is very common, (8051, MSP430 et al) and some use () or [] for indirection.
imo, () are used in expressions, so are best avoided.
Relative or absolute should not matter to users, so the common generic JMP Label
CALL Label
should use the smallest & most portable opcode.
If a user needs to force a different JMP, (rare) do not add yet-another-strange-char-tag, instead use
LJMP Label or maybe AJMP Label for Absolute RJMP Label for Relative
# as immediate is widely used so that can stay, but ##, @#, #@ should be avoided.
Usually there is only one choice for # opcode, but if someone really needs to force a 32b load,
then I've seen MOV Reg,#123L
or MOV Reg,#uint32(ConstExpression)
and these days, I'd lean toward the type cast with a clear numeric size, as that can be used in many contexts and is unambigious and non cryptic.
Dave, nice job on pfth! Seems to work. Be neat if set bit stuff worked on port B, then I could set leds on my DE2-115 setup...
Actually most of the P2-specific words are incorrect in the code I posted since they were based on an earlier version of the P2 before registers were reassigned. You could define the following words to work with port B:
"MOV Reg,#uint32(ConstExpression)" I really don't think much of that to be honest. We aren't that far from a clean, easy syntax, without all that cruft found in "those other assemblers"
The proposal Seairth put there is easy and clean.
And this: Relative or absolute should not matter to users...
"MOV Reg,#uint32(ConstExpression)" I really don't think much of that to be honest.
It is covering a quite rare usage of force a 64b opcode for what may be a smaller immediate load - Litmus Test: Take it to a student who has some language background, and ask them that they think it does.
The emphasis needs to be on Human Readable - 'cruft' is imprecise.
Yes, an align compiler instruction would be nice. Accessing aligned longs and words is more efficient than unaligned accesses, and it will help in porting existing P1 code that required alignment.
ALIGN
is the common way for ASMs to manage this, but you may be able to patch a ALIGN macro in the meantime, if present P2 asm allows equiv of
ORG (PC AND -3)+4
I was just looking for that construct. We have used it before.
@jmg
I agree with you on the current state.of PASM. And I know it will get much better too.
I very strongly disagree on what better is.
P1 PASM is excellent, and it shares a lot of lean, powerful iprrators with SPIN.
This.P2 PASM gets better in that direction. The moves you suggest come from more messy, less unified more character heavy environments. And those have their merits too, but they arent the lean, fun, powerful thing SPIN and PASM are, and I know I speak for a lot of people when I do so in order to stay focused on that path.
Chip likes brevity. And here is the thing about that: people have to learn either way.
We do not get SPIN and PASM as one unified thing by doing the same non unified things seen elsewhere. One or the other.
If this were brand new, and there was not a totally proven P1 legacy, I would hold a different opinion.
But there is, and its great.
Those little operators read just fine after some learning. The same kind of learning prople must do anytime they are faced with a new and different thing, and the P2 is a new and different thing that will only benefit from the same vision applied to P1.
Which is precisely why I don't think much of many syntax suggestions you have made. They are borrowed bits out of context.
There will be plenty of time for alternative assemblers, compilers, etc... gcc, forth, gas, who knows?
Let SPIN and PASM be the great thing they should be. Any more "human readable" thing can compete in due time. There are kinds of humans and kinds of readable...
Besides, I'll just fork the whole damn thing and gather friends to make it happen anyway.
This.P2 PASM gets better in that direction. The moves you suggest come from more messy, less unified more character heavy environments.
Nope, the moves I suggest come from Human readable,
and I'm thinking ahead to NEW USERS., which Parallax should be doing too, if they hope P2 hits critical mass..
And those have their merits too, but they arent the lean, fun, powerful thing SPIN and PASM are, and I know I speak for a lot of people when I do so in order to stay focused on that path.
Chip likes brevity. And here is the thing about that: people have to learn either way.
If that were really true, everyone would be using forth - that wins for 'lean' and 'brevity'.
There are very good reasons why forth is such a small niche - is it simply not Human Portable.
The new users P2 needs to attract will come from C and other modern HLLs, but they will need to use ASM more on a P2, than they do on their Raspberry Pi's or OS-based PCs. That boundary is where Parallax need to reduce the culture shock.
Spaghetti soup and (more?) hieroglyphs are not the solution to that problem..
@david. Yeah,.im fone with it, and was just pointing out some useful syntax from the P1 tools. Those expressions are not so ugly when dealing with long sets of mixed format data. $45, "hello", %00_10_11, 50...
Either is fine though. Maybe keep the p1 syntax, for porting and existing tools, like image to data type things and add a nice one for use in a code context.
@jmg
New users will get gcc, gas, forth, SPIN, PBASIC, and who knows what else? Heater is crazy enough to stuff Javascript on the thing. Maybe I will send him kit just to see it happen too.
There is no reason to bend SPIN and PASM away from the excellent p1 legacy.
Besides, there are lots of kinds of new users. There will be also lots of people making tools for them as well as it should be.
We got C after a considerable discussion of this kind and new peeps are happy either way. They get choices and good ones, as it should be. P2 is no different.
And say what you want, the combo of SPIN and PASM brought in a lot.of people who would never have bothered, myself included. Those people got us here too and need a path forward.
This is an old discussion. We got gcc to deal with that shock, and it played out just fine, just as it will this time too.
Even better this time is the likelihood of gcc being there and solid from the beginning.
Non issue at this stage. Part of the design goal here is fun and a bit wild of a programming environment. SPIN and PASM are great fun, and that is important to carry forward.
As for those people needing to use ASM, who are you kidding? P1 PASM is easy, and sweet. Its cake compared to most others. And, by the way, assembly language varies a lot. Why? Because the devices vary a lot, and I submit the more differentiated a device is, the more its assembly is going to vary, and that is OK and a good thing too.
We can and will get P2 close to the p1 experience, as we should. Its a great experience. Besides,.people getting into assembly will also be expecting to learn about it and they will do that on every assembly environment and device they encounter. Non issue.
Those other HLL tools will also frequenty have their assembler variants, and it all will play out just fine too.
@david. Yeah,.im fone with it, and was just pointing out some useful syntax from the P1 tools. Those expressions are not so ugly when dealing with long sets of mixed format data. $45, "hello", %00_10_11, 50...
Either is fine though. Maybe keep the p1 syntax, for porting and existing tools, like image to data type things and add a nice one for use in a code context.
@jmg
My problem is not knowing which is which:
label byte word 0 'should produce a word aligned byte
Without the comment, how would I know if it means a word with byte alignment or a byte with word alignment.
Because gcc is not SPIN. Its that simple and there will be two no matter what, probably more.
SPIN and PASM are linked together in productive and easy to use ways. The amount of Smile a person has to know to do the same in many other environments is high by comparison.
That is precisely why I am a strong advocate that continue. Its worth having.
Anyone who wants to mooch code can read it. Happens all the time.
Hmmm... That's pretty ugly. What about an align pseudo-op? So you would do this:
align long
foo long $1234
Works fine, can be done with a macro in the short term and become a valid pseudo-op longer term.
Even Align 4 is ok.
Personally, these days I try to avoid 'long' and 'int' as any size indicators, as they vary so much from platform to platform there is no guarantee users know what size they convey, especially across language barriers too...
( eg google finds this very easily sizeof(long)=8 or 64 bits )
That does not answer the question, which was about assemblers.
PASM should trend to become more like gas et al, not diverge to make code harder to read and port. That is why ad-hoc band-aids are a long term bad idea.
I doubt anyone will fill P2's 512k with code entirely in ASM, but I expect they will need to use some ASM.
That is why co-operation with multiple HLLs is important to consider now, divergence should be avoided.
That does not answer the question, which was about assemblers.
PASM should trend to become more like gas et al, not diverge to make code harder to read and port. That is why ad-hoc band-aids are a long term bad idea.
I doubt anyone will fill P2's 512k with code entirely in ASM, but I expect they will need to use some ASM.
That is why co-operation with multiple HLLs is important to consider now, divergence should be avoided.
And that's why PASM needs to be able to cooperate with Spin. PASM should not diverge from Spin.
That does not answer the question, which was about assemblers.
PASM should trend to become more like gas et al, not diverge to make code harder to read and port. That is why ad-hoc band-aids are a long term bad idea.
@jmg: I think this gets at our differences. And first, absolutely not! GAS has nothing to do with why SPIN and PASM are great. It won't ever either. It's not designed in the same way, nor with the same mindset or even goals.
With SPIN and PASM, there isn't just an assembler. It's one thing! SPIN and PASM can, if you want, exist in one file! In fact, the whole dang application can be one file, bits of SPIN, PASM, DATA, whatever. And on P2, with the nice HUBEXEC model, we can now blend them even more, with a clean, easy, potent syntax. SPIN+inline PASM will sing, and I for one don't want to see that potential get all buggered up with this idea that everything needs to look and act like GAS.
There have been some environments that did this in the past. Ever play the game "ELITE" That's a classic, packing a whole world into 32K. Done on the BBC Micro, which by the way, unified Assembly and BASIC in much the same way SPIN and PASM are unified. The Beeb actually was a closer union, and that's due to the execute model possible on those chips back then not being possible on a P1, but it is possible on a P2.
What people did was prototype in BASIC, then they added assembly, then they refined the data, wrote more in BASIC, then continued the cycle, until they had a mostly assembly language program! That approach has very serious merits, and it's worth having around. Despite the execute model limits we have on P1, that very same kind of approach makes sense, and it's just as easy as it ever was too.
Going THAT way with SPIN + PASM makes the most sense.
For the others, gcc is there, and it's the basis for a whole ton of stuff that also makes a ton of sense.
If you want an "assembler", that is what GAS actually is. It can be used for the purposes you describe, and it's portable, and standard in the ways you describe too. You know, Linus made his own when he wrote for the Propeller. It's a pretty awesome assembler, and it has nothing to do with SPIN or gcc. That's an assembler. It's just a piece. GAS is just a piece, though it's made to work with gcc and binutils and friends, and that's a bit more verbose and complicated because it's intended to be portable, etc...
All good! Seriously. But that's not the only way people might want to go.
The people who want SPIN+PASM don't want GAS, nor do they want "an assembler" They want the P1 environment of SPIN+PASM, as it currently exists, and they want it enhanced to help make the best of the new P2 chip too. They want to jump on a Propeller, knock it out, tune it up, nail it and be done! They aren't writing for every possible device in the world. They are writing for the device they want to write on and they want to get what they want done and they don't really care so much about how easy that code is to get into gcc or whatever. And that's just fine too.
Right now, Pnut looks a lot like an assembler. That's only due to the fact that we've not yet reached the point where it makes sense to begin weaving SPIN into the mix. But, Pnut will take common SPIN statements and expressions now. Or at least the last one I tried did. They get developed together, and the resulting tool does it all, and ideally we get an on-chip version of that to work with as well.
Chip works in x86 assembly language to unify the logic in the P2 and the tools, all as one thing. A lot of the "wild" nature of SPIN+PASM comes from that lean implementation too. A common expression parser would be one example. The same sorts of expressions we might use in SPIN, can be input as immediate assembly constants, or can be included in data statements. All those little operators are common.
When you learn something about SPIN, you also learn a lot about PASM too. The reverse is less true, but still somewhat true, in that SPIN can use the data and operators in similar ways.
And this brings synergies. Often, in SPIN, one can type a small string of operators and know those boil right down to PASM assembly instructions. On P1, this got compiled to bytecode for a lot of reasons, but on P2, it's going to result in native machine code, or ideally byte code, depending on what the programmer wants to do. If they want to optimize for space, and use some PASM for speed, they can target bytecode, and use a little bit of inline or P1 style COG PASM to get it done, and it won't be the complicated, syntax, directive laden thing it is to do in many other HLL languages not designed in that way.
When you suggest fairly radical deviations in PASM right now, you are also either suggesting we add those things to SPIN, or are breaking the unity and all the advantages that the two of them have.
Lots of us simply do not want that and don't need it. That's where the friction is.
Now, the GCC tools address that very well, and it's going to work out just fine, and just as it largely has on P1. The only bummer with P1 is we really didn't know how to do C on a P1 that made any sense! Once Bill Henning figured out LMM, the doors opened, and we got PropGCC, and it works just great!
There is a nicely growing body of code libraries and snippets that everyone can use. Additionally, COG type code can be encapsulated and used in GCC anyway, regardless of whether it was done in SPIN+PASM, or GAS, or some other thing. Those options are there, and will be there, and will make more sense on P2 because we've got much better and more flexible execute options on P2 that were not present on P1.
What you see as 'ad-hoc' band-aids is actually the organic resolution of a lean, efficient, sensible syntax in progress. It will get whittled down to a set that works really well, and that will have SPIN and the unified environment to come in mind.
And yes, it's not standard, yes it's not portable across a lot of other things, and that's all just fine! Many of us could care less, or if we do care, we know that there are things to be done to help people get where they need to be without also forcing them out of a pretty sweet programming environment.
When the core work on P2 gets done, OpenSpin will follow, and that can be the basis for all sorts of stuff that will make all sorts of sense with various HLL options out there.
And one last thing on code and "counter productive"
Have you actually programmed on a Propeller in SPIN+PASM? Seriously. I've asked this before and never did get an answer that I can recall. And I keep asking, because you really don't seem to get what SPIN + PASM is all about.
Don't knock it, until you try it. And if it's just not your thing, great! GCC will be right there for you and life is good. But those of us who love it, because we can knock out great things quick and fun have our reasons, and those are perfectly valid reasons.
Have you ever used cool video objects, sound, etc...? I can tell you 100 percent that a whole bunch of cool stuff would not even be an option to mooch code from without SPIN+PASM, because a lot of people wouldn't have bothered at all had SPIN+PASM not been so damn good.
So what you really need to think hard about is simple:
Would you rather have code to read and use, or not? If the effort to mangle SPIN+PASM into some ugly mess is successful, I can assure you there won't be code from some people.
...or, they might just do what I said and get together and just do it anyway, but let's say the motivation for that isn't there for grins.
What then?
Right now, with SPIN+PASM on track to continue the good things that got started on P1, there is a nice body of code to get working on P2, and nice people itching to do that. If that changes?
Why bother? Maybe moving on makes real sense. No joke. It's not a threat or anything like that. It's a simple reality. We've got a lot of cool stuff on P1 that is easy to use, MIT licensed, and the whole nine, and a bunch of that is linked to SPIN+PASM.
When you suggest fairly radical deviations in PASM right now, you are also either suggesting we add those things to SPIN, or are breaking the unity and all the advantages that the two of them have.
I don't think anything I've suggested is a "fairly radical deviation", merely simple attention to details, that serve to make PASM more portable, and easier for new users.
You seem to believe this is mutually exclusive, it is not.
It is not difficult to make Assemblers more compatible, but I will admit PNUT being coded in x86 Assembler, is not the most productive platform to allow easy addition of intelligence and simple aliasing.
Interrupts! What did you and others say about them?
As I recall, it was something along the lines of, "don't take the options from the USERS" right?
Well, guess what! We got 'em. The option is there.
Consider showing your SPIN+PASM peers here the same sort of consideration.
And WHO exactly was first out of the gate to call that as the good decision it was?
Me. Despite being a huge critic, it's a good call. The P2 design as it's playing out will very seriously benefit from that decision, and I had absolutely no problem saying it either.
There are multiple interests here, and it's not all about one unified body of code everywhere. Different strokes for different folks.
I'll bet a cookie you haven't touched it. If I'm wrong, fine. I'll apologize in advance.
But I think I'm right, and that means you quite simply do not know what you are talking about when it comes to SPIN+PASM and what matters and what does not: mutually exclusive is a case in point. It's not about more portable. It's all about more fun, quick, easy, fast, potent, lean.
It is mutually exclusive and for all the little reasons I and others have been writing here for some time now.
There are multiple interests here, and it's not all about one unified body of code everywhere. Different strokes for different folks.
Absolutely agree.
So why make it harder to copy/paste any block of assembler code, than it needs to be ?
Why make it harder to maintain, and harder for any new user to read ?
It is the simplest Assembler syntax levels I focus on, not the higher level wrappers.
Learn from what others have done, and when PASM needs new features, draw from that, do not invent yet more hieroglyphs that cause more divergence.
The devil is in the details.
Not that it matters much, however I think jmg is quite correct in pointing out some serious, fundamental issues that should be carefully considered.
Parallax needs to recoup some investment money on the P2, and to do that they need new users.
Making it easier for new people to get spun up on the P2 should be something looked at not just from a technical POV.
Like it or not, interested newcomers are going to look at example code, and the more human readable or similar it is to existing 'standard' ASM, the perceived barrier to entry will be lower.
Making the P2 a bit more 'standard' vs 'red-headed step-child'-like seems like it could lead to better exposure and uptake/$$.
Comments
A while back, I suggested the following:
BYTE/WORD/LONG : aligned data
PBYTE/PWORD/PLONG : packed data
This way, BYTE/WORD/LONG continue to work as everyone is already familiar with, while the P* variant provides explicit indication of intent.
It is fast turning into spaghetti soup and hieroglyphs, and I thinks needs a proper cleanup pass.
Most common usage should be the cleanest, and human-readable trumps saving characters.
labels as destinations are the most common usage in ASM, so
JMP Label
is the cleanest and very widely understood.
That leaves indirect needing a form
JMP @ Register
JMP @ PC+Register 'JMPREL
is very common, (8051, MSP430 et al) and some use () or [] for indirection.
imo, () are used in expressions, so are best avoided.
Relative or absolute should not matter to users, so the common generic
JMP Label
CALL Label
should use the smallest & most portable opcode.
If a user needs to force a different JMP, (rare) do not add yet-another-strange-char-tag, instead use
LJMP Label or maybe
AJMP Label for Absolute
RJMP Label for Relative
# as immediate is widely used so that can stay, but ##, @#, #@ should be avoided.
Usually there is only one choice for # opcode, but if someone really needs to force a 32b load,
then I've seen
MOV Reg,#123L
or
MOV Reg,#uint32(ConstExpression)
and these days, I'd lean toward the type cast with a clear numeric size, as that can be used in many contexts and is unambigious and non cryptic.
Regarding moving the hub-write-interrupt vectors to the end of the hub... before they were moved, I liked the idea of
WRLONG message, #coghubint ' to send a message
RDLONG whatmsg, #coghubint ' for the interrupt to read the message
Neat, fast, single long, single hub access
Now that they have been moved, we would have to use either PTRA or PTRB to be able to do the same in a single instruction
But I like having them at the top...
So how about
COGINTREAD#cog message ' reads the message sent by the interrupt that was received
COGINT #cog, message/# ' sends a interrput message to #cog
#cog only needs 4 bits, allows keeping the vectors up high in the hub, preserves single-long system calls
The proposal Seairth put there is easy and clean.
And this: Relative or absolute should not matter to users...
Really? Depends on the users, doesn't it?
As I said, the smallest and most portable should be the default, with a user choice to override.
It is applying KISS with an emphasis on Human Readable.
Present PASM is a very long way from Human Readable, just look at all the posts !!
It needs more than a small band-aid.
The emphasis needs to be on Human Readable - 'cruft' is imprecise.
ALIGN
is the common way for ASMs to manage this, but you may be able to patch a ALIGN macro in the meantime, if present P2 asm allows equiv of
ORG (PC AND -3)+4
@jmg
I agree with you on the current state.of PASM. And I know it will get much better too.
I very strongly disagree on what better is.
P1 PASM is excellent, and it shares a lot of lean, powerful iprrators with SPIN.
This.P2 PASM gets better in that direction. The moves you suggest come from more messy, less unified more character heavy environments. And those have their merits too, but they arent the lean, fun, powerful thing SPIN and PASM are, and I know I speak for a lot of people when I do so in order to stay focused on that path.
Chip likes brevity. And here is the thing about that: people have to learn either way.
We do not get SPIN and PASM as one unified thing by doing the same non unified things seen elsewhere. One or the other.
If this were brand new, and there was not a totally proven P1 legacy, I would hold a different opinion.
But there is, and its great.
Those little operators read just fine after some learning. The same kind of learning prople must do anytime they are faced with a new and different thing, and the P2 is a new and different thing that will only benefit from the same vision applied to P1.
Which is precisely why I don't think much of many syntax suggestions you have made. They are borrowed bits out of context.
There will be plenty of time for alternative assemblers, compilers, etc... gcc, forth, gas, who knows?
Let SPIN and PASM be the great thing they should be. Any more "human readable" thing can compete in due time. There are kinds of humans and kinds of readable...
Besides, I'll just fork the whole damn thing and gather friends to make it happen anyway.
Nope, the moves I suggest come from Human readable,
and I'm thinking ahead to NEW USERS., which Parallax should be doing too, if they hope P2 hits critical mass..
If that were really true, everyone would be using forth - that wins for 'lean' and 'brevity'.
There are very good reasons why forth is such a small niche - is it simply not Human Portable.
The new users P2 needs to attract will come from C and other modern HLLs, but they will need to use ASM more on a P2, than they do on their Raspberry Pi's or OS-based PCs.
That boundary is where Parallax need to reduce the culture shock.
Spaghetti soup and (more?) hieroglyphs are not the solution to that problem..
Either is fine though. Maybe keep the p1 syntax, for porting and existing tools, like image to data type things and add a nice one for use in a code context.
@jmg
New users will get gcc, gas, forth, SPIN, PBASIC, and who knows what else? Heater is crazy enough to stuff Javascript on the thing. Maybe I will send him kit just to see it happen too.
There is no reason to bend SPIN and PASM away from the excellent p1 legacy.
Besides, there are lots of kinds of new users. There will be also lots of people making tools for them as well as it should be.
We got C after a considerable discussion of this kind and new peeps are happy either way. They get choices and good ones, as it should be. P2 is no different.
And say what you want, the combo of SPIN and PASM brought in a lot.of people who would never have bothered, myself included. Those people got us here too and need a path forward.
This is an old discussion. We got gcc to deal with that shock, and it played out just fine, just as it will this time too.
Even better this time is the likelihood of gcc being there and solid from the beginning.
Non issue at this stage. Part of the design goal here is fun and a bit wild of a programming environment. SPIN and PASM are great fun, and that is important to carry forward.
As for those people needing to use ASM, who are you kidding? P1 PASM is easy, and sweet. Its cake compared to most others. And, by the way, assembly language varies a lot. Why? Because the devices vary a lot, and I submit the more differentiated a device is, the more its assembly is going to vary, and that is OK and a good thing too.
We can and will get P2 close to the p1 experience, as we should. Its a great experience. Besides,.people getting into assembly will also be expecting to learn about it and they will do that on every assembly environment and device they encounter. Non issue.
Those other HLL tools will also frequenty have their assembler variants, and it all will play out just fine too.
I'm done on this now.
It should be kept along with all the other great ways to express data in PASM and SPIN.
Or not... Frankly, the pc expression is just fine with me. And those operators are common to SPIN as well, sans the $ one.
That can only be counter productive.
Users will need to be able to mix HLL and ASM, as well as easily harvest code from examples.
SPIN and PASM are linked together in productive and easy to use ways. The amount of Smile a person has to know to do the same in many other environments is high by comparison.
That is precisely why I am a strong advocate that continue. Its worth having.
Anyone who wants to mooch code can read it. Happens all the time.
Even Align 4 is ok.
Personally, these days I try to avoid 'long' and 'int' as any size indicators, as they vary so much from platform to platform there is no guarantee users know what size they convey, especially across language barriers too...
( eg google finds this very easily sizeof(long)=8 or 64 bits )
I agree, the align pseudo-op is clearer.
PASM should trend to become more like gas et al, not diverge to make code harder to read and port. That is why ad-hoc band-aids are a long term bad idea.
I doubt anyone will fill P2's 512k with code entirely in ASM, but I expect they will need to use some ASM.
That is why co-operation with multiple HLLs is important to consider now, divergence should be avoided.
And that's why PASM needs to be able to cooperate with Spin. PASM should not diverge from Spin.
Spin simply carries PASM sources.
- but users will expect to be able to take multiple ASM examples and use them in any HLL (Spin, C, PropBASIC, etc )
Here is a topical example thread :
http://forums.parallax.com/discussion/162433/propeller-gcc-gnu-assembler-alignment-issue
Take a glance at the ASM listing.
There is no real reason PASM/PNUT cannot be designed to assemble that, and still work fine within P2-Spin.
@jmg: I think this gets at our differences. And first, absolutely not! GAS has nothing to do with why SPIN and PASM are great. It won't ever either. It's not designed in the same way, nor with the same mindset or even goals.
With SPIN and PASM, there isn't just an assembler. It's one thing! SPIN and PASM can, if you want, exist in one file! In fact, the whole dang application can be one file, bits of SPIN, PASM, DATA, whatever. And on P2, with the nice HUBEXEC model, we can now blend them even more, with a clean, easy, potent syntax. SPIN+inline PASM will sing, and I for one don't want to see that potential get all buggered up with this idea that everything needs to look and act like GAS.
There have been some environments that did this in the past. Ever play the game "ELITE" That's a classic, packing a whole world into 32K. Done on the BBC Micro, which by the way, unified Assembly and BASIC in much the same way SPIN and PASM are unified. The Beeb actually was a closer union, and that's due to the execute model possible on those chips back then not being possible on a P1, but it is possible on a P2.
What people did was prototype in BASIC, then they added assembly, then they refined the data, wrote more in BASIC, then continued the cycle, until they had a mostly assembly language program! That approach has very serious merits, and it's worth having around. Despite the execute model limits we have on P1, that very same kind of approach makes sense, and it's just as easy as it ever was too.
Going THAT way with SPIN + PASM makes the most sense.
For the others, gcc is there, and it's the basis for a whole ton of stuff that also makes a ton of sense.
If you want an "assembler", that is what GAS actually is. It can be used for the purposes you describe, and it's portable, and standard in the ways you describe too. You know, Linus made his own when he wrote for the Propeller. It's a pretty awesome assembler, and it has nothing to do with SPIN or gcc. That's an assembler. It's just a piece. GAS is just a piece, though it's made to work with gcc and binutils and friends, and that's a bit more verbose and complicated because it's intended to be portable, etc...
All good! Seriously. But that's not the only way people might want to go.
The people who want SPIN+PASM don't want GAS, nor do they want "an assembler" They want the P1 environment of SPIN+PASM, as it currently exists, and they want it enhanced to help make the best of the new P2 chip too. They want to jump on a Propeller, knock it out, tune it up, nail it and be done! They aren't writing for every possible device in the world. They are writing for the device they want to write on and they want to get what they want done and they don't really care so much about how easy that code is to get into gcc or whatever. And that's just fine too.
Right now, Pnut looks a lot like an assembler. That's only due to the fact that we've not yet reached the point where it makes sense to begin weaving SPIN into the mix. But, Pnut will take common SPIN statements and expressions now. Or at least the last one I tried did. They get developed together, and the resulting tool does it all, and ideally we get an on-chip version of that to work with as well.
Chip works in x86 assembly language to unify the logic in the P2 and the tools, all as one thing. A lot of the "wild" nature of SPIN+PASM comes from that lean implementation too. A common expression parser would be one example. The same sorts of expressions we might use in SPIN, can be input as immediate assembly constants, or can be included in data statements. All those little operators are common.
When you learn something about SPIN, you also learn a lot about PASM too. The reverse is less true, but still somewhat true, in that SPIN can use the data and operators in similar ways.
And this brings synergies. Often, in SPIN, one can type a small string of operators and know those boil right down to PASM assembly instructions. On P1, this got compiled to bytecode for a lot of reasons, but on P2, it's going to result in native machine code, or ideally byte code, depending on what the programmer wants to do. If they want to optimize for space, and use some PASM for speed, they can target bytecode, and use a little bit of inline or P1 style COG PASM to get it done, and it won't be the complicated, syntax, directive laden thing it is to do in many other HLL languages not designed in that way.
When you suggest fairly radical deviations in PASM right now, you are also either suggesting we add those things to SPIN, or are breaking the unity and all the advantages that the two of them have.
Lots of us simply do not want that and don't need it. That's where the friction is.
Now, the GCC tools address that very well, and it's going to work out just fine, and just as it largely has on P1. The only bummer with P1 is we really didn't know how to do C on a P1 that made any sense! Once Bill Henning figured out LMM, the doors opened, and we got PropGCC, and it works just great!
There is a nicely growing body of code libraries and snippets that everyone can use. Additionally, COG type code can be encapsulated and used in GCC anyway, regardless of whether it was done in SPIN+PASM, or GAS, or some other thing. Those options are there, and will be there, and will make more sense on P2 because we've got much better and more flexible execute options on P2 that were not present on P1.
What you see as 'ad-hoc' band-aids is actually the organic resolution of a lean, efficient, sensible syntax in progress. It will get whittled down to a set that works really well, and that will have SPIN and the unified environment to come in mind.
And yes, it's not standard, yes it's not portable across a lot of other things, and that's all just fine! Many of us could care less, or if we do care, we know that there are things to be done to help people get where they need to be without also forcing them out of a pretty sweet programming environment.
When the core work on P2 gets done, OpenSpin will follow, and that can be the basis for all sorts of stuff that will make all sorts of sense with various HLL options out there.
And one last thing on code and "counter productive"
Have you actually programmed on a Propeller in SPIN+PASM? Seriously. I've asked this before and never did get an answer that I can recall. And I keep asking, because you really don't seem to get what SPIN + PASM is all about.
Don't knock it, until you try it. And if it's just not your thing, great! GCC will be right there for you and life is good. But those of us who love it, because we can knock out great things quick and fun have our reasons, and those are perfectly valid reasons.
Have you ever used cool video objects, sound, etc...? I can tell you 100 percent that a whole bunch of cool stuff would not even be an option to mooch code from without SPIN+PASM, because a lot of people wouldn't have bothered at all had SPIN+PASM not been so damn good.
So what you really need to think hard about is simple:
Would you rather have code to read and use, or not? If the effort to mangle SPIN+PASM into some ugly mess is successful, I can assure you there won't be code from some people.
...or, they might just do what I said and get together and just do it anyway, but let's say the motivation for that isn't there for grins.
What then?
Right now, with SPIN+PASM on track to continue the good things that got started on P1, there is a nice body of code to get working on P2, and nice people itching to do that. If that changes?
Why bother? Maybe moving on makes real sense. No joke. It's not a threat or anything like that. It's a simple reality. We've got a lot of cool stuff on P1 that is easy to use, MIT licensed, and the whole nine, and a bunch of that is linked to SPIN+PASM.
I don't think anything I've suggested is a "fairly radical deviation", merely simple attention to details, that serve to make PASM more portable, and easier for new users.
You seem to believe this is mutually exclusive, it is not.
It is not difficult to make Assemblers more compatible, but I will admit PNUT being coded in x86 Assembler, is not the most productive platform to allow easy addition of intelligence and simple aliasing.
Interrupts! What did you and others say about them?
As I recall, it was something along the lines of, "don't take the options from the USERS" right?
Well, guess what! We got 'em. The option is there.
Consider showing your SPIN+PASM peers here the same sort of consideration.
And WHO exactly was first out of the gate to call that as the good decision it was?
Me. Despite being a huge critic, it's a good call. The P2 design as it's playing out will very seriously benefit from that decision, and I had absolutely no problem saying it either.
There are multiple interests here, and it's not all about one unified body of code everywhere. Different strokes for different folks.
Even once? Seriously?
I'll bet a cookie you haven't touched it. If I'm wrong, fine. I'll apologize in advance.
But I think I'm right, and that means you quite simply do not know what you are talking about when it comes to SPIN+PASM and what matters and what does not: mutually exclusive is a case in point. It's not about more portable. It's all about more fun, quick, easy, fast, potent, lean.
It is mutually exclusive and for all the little reasons I and others have been writing here for some time now.
Absolutely agree.
So why make it harder to copy/paste any block of assembler code, than it needs to be ?
Why make it harder to maintain, and harder for any new user to read ?
It is the simplest Assembler syntax levels I focus on, not the higher level wrappers.
Learn from what others have done, and when PASM needs new features, draw from that, do not invent yet more hieroglyphs that cause more divergence.
The devil is in the details.
Not that it matters much, however I think jmg is quite correct in pointing out some serious, fundamental issues that should be carefully considered.
Parallax needs to recoup some investment money on the P2, and to do that they need new users.
Making it easier for new people to get spun up on the P2 should be something looked at not just from a technical POV.
Like it or not, interested newcomers are going to look at example code, and the more human readable or similar it is to existing 'standard' ASM, the perceived barrier to entry will be lower.
Making the P2 a bit more 'standard' vs 'red-headed step-child'-like seems like it could lead to better exposure and uptake/$$.
We all do want that, right?