It seems like all this "New Spin" talk is taking away from the P2 development. I'd prefer seeing the P2 sooner than to have New Spin and then P2 later. Do we really even need a new Spin? Why not just use the old Spin and add a few intrinsics to handle the new features of the P2?
Dave raises a good point here -- if the interpreter is not built into ROM (and/or if Spin2 is compiled to PASM) then it can be developed in parallel with or after the chip itself. It's tempting to get carried away with adding features to Spin2, but really it would be easy to get Spin1 up and running on the P2 (I did it with an older P2 and fastspin last year, and I think Cluso did it with the Spin1 interpreter as well).
I agree that getting the P2 out should be the top priority, but I think it would also be beneficial to hash out some of the points raised for the new Spin interpreter/compiler as well, particularly for the PASM compiler. One of the things this discussion brought to mind was that the early asm compilers went from having the programmer specify the addressing modes to having the compiler select the optimum mode automatically. Perhaps that could be done for PASM as well.
Ken has said before that they won't launch the P2 chip without software such as Spin and C, and probably now he'd like Blockly on it too. He also wants it to have cross platform support from the start instead of only windows like with P1.
Chip has already made adjustments to the Verilog based on what he's done so far for the new Spin, and there may be more. This is part of the process he wants to do, so lets help support it instead of telling him to do something else.
They need the software ready for launch in order to be able to actually sell it. Spending a pile of money on a chip right now, that they then have to sit on for months while software is made is bad for business. Doing the "quick" path as some of you have suggested is a bad first impression, and likely to result in less return. They need good, cross platform, software support for the P2 in order to sell it.
Also, most of us are not the primary target audience. We can deal with a P2 that doesn't have finished software. Parallax targets education first, after that commercial users (a few of you included), then hobbyists. Most of there target audience won't even look at it without the finished software support.
Maybe it's just me, but my main problem is forgetting the # with jmp and djnz and call, etc.
And, 99-100% of the time I use these statement in the way that needs a "#".
For me, I'd rather stick to the existing syntax and have the compiler give a warning if these commands are used without the "#".
Warnings don't need to be obnoxious, you could have to use the menu to see them or something.
Just something one could check if don't understand what's wrong...
That one seems crappy to me. The intent or type rule can work, we just need to classify the instructions. We type i all the time, and may still see ourselves bodge it.
COGS are register to register design for most operations. That warrants the syntax we've got. A carve out for the other case makes sense.
I feel now no matter what we do, people will make the mistake. A jmp loads the PC, different from most instructions. That implied destination is where all the disconnects are.
We communicate that and no actual changes are needed!
If we make the change, and I don't care as long as it's limited to the odd cases, then it can help to communicate that, which your syntax does.
Given HUBEXEC basically turns the whole COG into registers, and that people can mix, we should make a doc on addressing forms.
Maybe I'll start on that when the syntax is sorted.
I know I got tripped up on jmp a whole lot less when I realized the target is an unaddressed register, as opposed to basically everything else being register to register.
It would be nice to agree on how we talk about these too.
To me, mov r1, #r2
R1 = absolute cog address
#r2 = immediate, some say literal here
Move works with values as the intent or target. Register to register explains why we dont ever have an immediate, or literal in the destination field. That would make no real sense.
In the source field, if we say "target source", and or say that is a value, it will all click. We want either the value contained in cog memory at an address, or we supply the value directly in the instruction. #
For jmp, it works with addresses, and the destination is implied, which I think should be the name of this addressing form.
Jmp r1
Jmp *r1
With the new syntax, we also have a name for the addressing mode. The implied destination makes sense now, and we either want an address value to load the PC with (r1), or we want the value contained in the cog memory at the address indicated by value to be loaded into the PC. (*r1)
These could be called implied indirect (*r1), and implied (r1)
My .02. How we say this matters, and its worth it so the majority of input cases are simple (mov r1, r2)
Then, mov r1, r2 and jmp r1 are differentiated by one vs two operands.
One operand is implied destination, two is explicit destination.
We then can list the modes and have it make a lot of sense.
There are only a few. And we then can talk about indexing, the instruction modify ALT and how it gets indexing and whatever else done.
For non-address operands, register is the default and # specifies a constant..
For address operands, constant is the defaullt and * specifies a register.
That's a simple syntax that does the job.
Sounds all good to me.
Can you give some code examples to show the new syntax, in all cases ?
(including pre/post inc, where they exist )
Do the examples ozpropdev gave above change ?
Ken has said before that they won't launch the P2 chip without software such as Spin and C, and probably now he'd like Blockly on it too. He also wants it to have cross platform support from the start instead of only windows like with P1.
Chip has already made adjustments to the Verilog based on what he's done so far for the new Spin, and there may be more. This is part of the process he wants to do, so lets help support it instead of telling him to do something else.
They need the software ready for launch in order to be able to actually sell it. Spending a pile of money on a chip right now, that they then have to sit on for months while software is made is bad for business. Doing the "quick" path as some of you have suggested is a bad first impression, and likely to result in less return. They need good, cross platform, software support for the P2 in order to sell it.
Also, most of us are not the primary target audience. We can deal with a P2 that doesn't have finished software. Parallax targets education first, after that commercial users (a few of you included), then hobbyists. Most of there target audience won't even look at it without the finished software support.
I'll add that the other thing 'software-now' gives, is better test coverage, and lower risk of a respin. It can actually means less time to a final working, ship-able chip.
One of the things this discussion brought to mind was that the early asm compilers went from having the programmer specify the addressing modes to having the compiler select the optimum mode automatically. Perhaps that could be done for PASM as well.
Yes, another MCU ASM I use now has explicit near and far opcodes, as well as generic ones that the assembler (re)sizes as small as it can.
With finite passes, there are limits to how well this 'auto' works, so having both covers all practical uses.
Barring adoption of something like jmpi and jmpr, I would rather keep the # for immediate and add * (or >) as an option for indirect. Then have the compiler issue a warning for naked jmp targets. This keeps it compatible with PASM1 but provides a warning mechanism if you don't specify exactly what you mean. I think that default behavior with naked targets might still lead to bugs and confusion.
I don't like the idea of the default case being issue a warning for code that is probably fine. Warnings should be for things that are likely to not be fine.
I much prefer just picking a syntax and adhering to it strictly, optional syntax leads to problems down the line.
I agree with Phil here. The existing syntax is actually consistant and clean.
It all boils down to what an implied destination, the PC, really means.
It means, a value is an address, because the implied destination uses it as an address.
Jmp written as "mov PC, r1" or "mov PC, #r1" works just fine with the existing syntax, as an example. The immediate, or literal # is the value assigned to the label address, and its a value that goes into the PC, which treats it as an address.
Isn't Chip's change using # for immediate/constants, and nothing for labels
"For non-address operands, register is the default and # specifies a constant..
For address operands, constant is the default and * specifies a register.
That's a simple syntax that does the job. "
Seems that gives the cleanest code.
P1 was rather unusual in that register space was entirely code space, and only absolute opcodes existed.
In P2 the concept of relocatable labels as code space addresses, and relative opcodes makes it more like 'normal/other' microcontrollers.
A Label in P2, no longer always has a register alias.
In the HUBEXEC space, its more like, but still pretty different.
A mov will do register to register in COG, not memory to memory. Wrbyte and friends are needed for that, and people still need to think through what that means.
I have nothing offer here but after reading some proposed "improvements" to Spin I'm a bit worried:
Use "=" instead of ":="
Use "{...}" instead of white space block delimiting.
Method/object references that can be passed around.
Introduce structures.
Inheritance.
Types: byte, world, long (signed an unsigned of course), float, method, object, whatever.
As I have said before, at some point this is recreating C++ !
Anyway, the point of my post, it reminded me of this humorous old skit about "fixing" the obvious spelling and grammatical inconsistencies in the English language:
"English in the Future
Directors at Daimler Benz and Chrysler have announced an agreement to adopt English as the preferred language for communications, rather than German, which was another possibility.
As part of the negotiations, directors at Chrysler conceded that English spelling has some room for improvement and have accepted a five-year phase-in plan. In the first year, "s" will be used instead of the soft "c". Also, the hard "c" will be replased with "k". Not only will this klear up konfusion, but komputers have one less letter.
There will be growing kompany enthusiasm in the sekond year when the troublesome "ph" will be replased by "f". This will make words like "fotograf" 20 persent shorter.
In the third year, DaimlerKhrysler akseptanse of the new spelling kan be expekted to reash the stage where more komplikated shanges are possible.
DaimlerKhrysler will enkourage the removal of double letters, whish have always ben a deterent to akurate speling. Also, al wil agre that the horible mes of silent "e"'s in the languag is disgrasful, and they would go.
By the fourth year, peopl wil be reseptiv to steps sush as replasing "th" with "z" and "w" by "v".
During ze fifz year, ze unesesary "o" kan be droped from vords kontaining "o", and similar shanges vud of kors be aplid to ozer kombinations of leters.
After zis fifz yer, ve vil hav a reli sensibl riten styl. Zer vil be no mor trubls or difikultis, and employes vil find it ezi to kommunikat viz eash ozer.
Ov kors al supliers vil be expekted to us zis for all busines komunikation via DaimlerKhrysler.
Perhaps make a list of the various choices and take a vote?
I sincerely hope this will not be a democratic process! We can suggest stuff, but Chip gets to make the final call. Otherwise it becomes "design by committee," and that hardly ever works out.
I've been going over the syntax and it's really hard to change the "#" paradigm, so that things make simple sense to your eyes. I'm going to just put this aside for now and go back to thinking about Spin 2.
I've been going over the syntax and it's really hard to change the "#" paradigm, so that things make simple sense to your eyes. I'm going to just put this aside for now and go back to thinking about Spin 2.
Pity. Maybe that was why this did not advance last time either....
I have nothing offer here but after reading some proposed "improvements" to Spin I'm a bit worried:
Use "=" instead of ":="
Use "{...}" instead of white space block delimiting.
Method/object references that can be passed around.
Introduce structures.
Inheritance.
Types: byte, world, long (signed an unsigned of course), float, method, object, whatever.
As I have said before, at some point this is recreating C++ !
Anyway, the point of my post, it reminded me of this humorous old skit about "fixing" the obvious spelling and grammatical inconsistencies in the English language:
"English in the Future
Directors at Daimler Benz and Chrysler have announced an agreement to adopt English as the preferred language for communications, rather than German, which was another possibility.
As part of the negotiations, directors at Chrysler conceded that English spelling has some room for improvement and have accepted a five-year phase-in plan. In the first year, "s" will be used instead of the soft "c". Also, the hard "c" will be replased with "k". Not only will this klear up konfusion, but komputers have one less letter.
There will be growing kompany enthusiasm in the sekond year when the troublesome "ph" will be replased by "f". This will make words like "fotograf" 20 persent shorter.
In the third year, DaimlerKhrysler akseptanse of the new spelling kan be expekted to reash the stage where more komplikated shanges are possible.
DaimlerKhrysler will enkourage the removal of double letters, whish have always ben a deterent to akurate speling. Also, al wil agre that the horible mes of silent "e"'s in the languag is disgrasful, and they would go.
By the fourth year, peopl wil be reseptiv to steps sush as replasing "th" with "z" and "w" by "v".
During ze fifz year, ze unesesary "o" kan be droped from vords kontaining "o", and similar shanges vud of kors be aplid to ozer kombinations of leters.
After zis fifz yer, ve vil hav a reli sensibl riten styl. Zer vil be no mor trubls or difikultis, and employes vil find it ezi to kommunikat viz eash ozer.
Ov kors al supliers vil be expekted to us zis for all busines komunikation via DaimlerKhrysler.
Perhaps make a list of the various choices and take a vote?
I sincerely hope this will not be a democratic process! We can suggest stuff, but Chip gets to make the final call. Otherwise it becomes "design by committee," and that hardly ever works out.
-Phil
Of course Chip makes the final call! Considering the nature of the folks on this forum I would expect that his choices would not be far from what the majority votes for.
Ken has said before that they won't launch the P2 chip without software such as Spin and C, and probably now he'd like Blockly on it too. He also wants it to have cross platform support from the start instead of only windows like with P1.
Chip has already made adjustments to the Verilog based on what he's done so far for the new Spin, and there may be more. This is part of the process he wants to do, so lets help support it instead of telling him to do something else.
They need the software ready for launch in order to be able to actually sell it. Spending a pile of money on a chip right now, that they then have to sit on for months while software is made is bad for business. Doing the "quick" path as some of you have suggested is a bad first impression, and likely to result in less return. They need good, cross platform, software support for the P2 in order to sell it.
Also, most of us are not the primary target audience. We can deal with a P2 that doesn't have finished software. Parallax targets education first, after that commercial users (a few of you included), then hobbyists. Most of there target audience won't even look at it without the finished software support.
Roy, I agree that software support should be available the same time the chip is. But the P2 chip probably won't happen until Xmas if we're lucky. So why not do the Spin development after the P2 has been sent out for layout and fab. There will be a window of 4 months or more where Chip will be waiting for the chip. By doing the Spin2 development now it's making the P2 development sequential instead of parallel. Why not make it parallel?
I understand that Chip is concerned that the Spin interpreter might uncover something that is needed in the silicon. So why not just extend the P1 Spin interpreter with P2-specific intrinsics instead of contemplating such huge changes. And if software support is so important at launch time why hasn't there been an effort to get GCC working on the P2? For the P2, I think C will be just as important as Spin.
... And if software support is so important at launch time why hasn't there been an effort to get GCC working on the P2? For the P2, I think C will be just as important as Spin.
Certainly a good point, I think P2-Opcodes are stable enough now, that GCC can be ported ?
... So why not do the Spin development after the P2 has been sent out for layout and fab. There will be a window of 4 months or more where Chip will be waiting for the chip. By doing the Spin2 development now it's making the P2 development sequential instead of parallel. Why not make it parallel?
I think it will largely be parallel - I don't see anyone advocating Silicon delay until release-quality software is done.
I understand that Chip is concerned that the Spin interpreter might uncover something that is needed in the silicon. So why not just extend the P1 Spin interpreter with P2-specific intrinsics instead of contemplating such huge changes.
I'd agree the focus should be on software test coverage, and faster-to-test pathways have appeal there.
The critical silicon area in byte-code engines, is the inner-most loops, and that does not take long to prove and tune.
(I'd also like to see this tested/tuned for XIP from parts like QuadSPIx2 and HyperFLASH)
Spin2cpp seems to already have a working P2 pathway ?
.. and of course Tachyon has P2 pathways - has Peter tried the new byte-opcode opcodes. on his byte/word engine ?
Spin2cpp seems to already have a working P2 pathway ?
Eric said that spin2cpp aka fastspin was able to generate P2 code for an earlier FPGA image. I imagine it wouldn't take too much work to update it to release 16 when that becomes available.
I'm thinking we've got too many DIR and OUT instructions:
EEEE 1101011 CZL DDDDDDDDD 001000000 DIRL {#}D {WC,WZ} DIR bit of pin D[5:0] = 0, C/!Z = IN bit.
EEEE 1101011 CZL DDDDDDDDD 001000001 DIRH {#}D {WC,WZ} DIR bit of pin D[5:0] = 1, C/!Z = IN bit.
EEEE 1101011 CZL DDDDDDDDD 001000010 DIRC {#}D {WC,WZ} DIR bit of pin D[5:0] = C, C/!Z = IN bit.
EEEE 1101011 CZL DDDDDDDDD 001000011 DIRNC {#}D {WC,WZ} DIR bit of pin D[5:0] = !C, C/!Z = IN bit.
EEEE 1101011 CZL DDDDDDDDD 001000100 DIRZ {#}D {WC,WZ} DIR bit of pin D[5:0] = Z, C/!Z = IN bit.
EEEE 1101011 CZL DDDDDDDDD 001000101 DIRNZ {#}D {WC,WZ} DIR bit of pin D[5:0] = !Z, C/!Z = IN bit.
EEEE 1101011 CZL DDDDDDDDD 001000110 DIRN {#}D {WC,WZ} DIR bit of pin D[5:0] = !bit, C/!Z = IN bit.
EEEE 1101011 CZL DDDDDDDDD 001000111 TESTNIN {#}D {WC,WZ} Test !IN bit of pin D[5:0], !C/Z = IN bit.
EEEE 1101011 CZL DDDDDDDDD 001001000 OUTL {#}D {WC,WZ} OUT bit of pin D[5:0] = 0, C/!Z = IN bit.
EEEE 1101011 CZL DDDDDDDDD 001001001 OUTH {#}D {WC,WZ} OUT bit of pin D[5:0] = 1, C/!Z = IN bit.
EEEE 1101011 CZL DDDDDDDDD 001001010 OUTC {#}D {WC,WZ} OUT bit of pin D[5:0] = C, C/!Z = IN bit.
EEEE 1101011 CZL DDDDDDDDD 001001011 OUTNC {#}D {WC,WZ} OUT bit of pin D[5:0] = !C, C/!Z = IN bit.
EEEE 1101011 CZL DDDDDDDDD 001001100 OUTZ {#}D {WC,WZ} OUT bit of pin D[5:0] = Z, C/!Z = IN bit.
EEEE 1101011 CZL DDDDDDDDD 001001101 OUTNZ {#}D {WC,WZ} OUT bit of pin D[5:0] = !Z, C/!Z = IN bit.
EEEE 1101011 CZL DDDDDDDDD 001001110 OUTN {#}D {WC,WZ} OUT bit of pin D[5:0] = !bit, C/!Z = IN bit.
EEEE 1101011 CZL DDDDDDDDD 001001111 TESTIN {#}D {WC,WZ} Test IN bit of pin D[5:0], C/!Z = IN bit.
EEEE 1101011 CZL DDDDDDDDD 001010000 FLTL {#}D {WC,WZ} OUT bit of pin D[5:0] = 0, DIR bit = 0, C/!Z = IN bit.
EEEE 1101011 CZL DDDDDDDDD 001010001 FLTH {#}D {WC,WZ} OUT bit of pin D[5:0] = 1, DIR bit = 0, C/!Z = IN bit.
EEEE 1101011 CZL DDDDDDDDD 001010010 FLTC {#}D {WC,WZ} OUT bit of pin D[5:0] = C, DIR bit = 0, C/!Z = IN bit.
EEEE 1101011 CZL DDDDDDDDD 001010011 FLTNC {#}D {WC,WZ} OUT bit of pin D[5:0] = !C, DIR bit = 0, C/!Z = IN bit.
EEEE 1101011 CZL DDDDDDDDD 001010100 FLTZ {#}D {WC,WZ} OUT bit of pin D[5:0] = Z, DIR bit = 0, C/!Z = IN bit.
EEEE 1101011 CZL DDDDDDDDD 001010101 FLTNZ {#}D {WC,WZ} OUT bit of pin D[5:0] = !Z, DIR bit = 0, C/!Z = IN bit.
EEEE 1101011 CZL DDDDDDDDD 001010110 FLTN {#}D {WC,WZ} OUT bit of pin D[5:0] = !bit, DIR bit = 0, C/!Z = IN bit.
EEEE 1101011 CZL DDDDDDDDD 001010111 FLTRND {#}D {WC,WZ} OUT bit of pin D[5:0] = RND, DIR bit = 0, C/!Z = IN bit. (will be in v16)
EEEE 1101011 CZL DDDDDDDDD 001011000 DRVL {#}D {WC,WZ} OUT bit of pin D[5:0] = 0, DIR bit = 1, C/!Z = IN bit.
EEEE 1101011 CZL DDDDDDDDD 001011001 DRVH {#}D {WC,WZ} OUT bit of pin D[5:0] = 1, DIR bit = 1, C/!Z = IN bit.
EEEE 1101011 CZL DDDDDDDDD 001011010 DRVC {#}D {WC,WZ} OUT bit of pin D[5:0] = C, DIR bit = 1, C/!Z = IN bit.
EEEE 1101011 CZL DDDDDDDDD 001011011 DRVNC {#}D {WC,WZ} OUT bit of pin D[5:0] = !C, DIR bit = 1, C/!Z = IN bit.
EEEE 1101011 CZL DDDDDDDDD 001011100 DRVZ {#}D {WC,WZ} OUT bit of pin D[5:0] = Z, DIR bit = 1, C/!Z = IN bit.
EEEE 1101011 CZL DDDDDDDDD 001011101 DRVNZ {#}D {WC,WZ} OUT bit of pin D[5:0] = !Z, DIR bit = 1, C/!Z = IN bit.
EEEE 1101011 CZL DDDDDDDDD 001011110 DRVN {#}D {WC,WZ} OUT bit of pin D[5:0] = !bit, DIR bit = 1, C/!Z = IN bit.
EEEE 1101011 CZL DDDDDDDDD 001011111 DRVRND {#}D {WC,WZ} OUT bit of pin D[5:0] = RND, DIR bit = 1, C/!Z = IN bit. (will be in v16)
I'm thinking we could get by with just FLTL..DRVRND and ditch DIRL..TESTIN. This would lighten the logic a bit.
It would mean that all DIR/OUT instructions would always affect a DIR bit and an OUT bit. The IN would always be reported back via C. Can you think of a case where DIRL..TESTIN is really necessary? It's looking to me like we could get rid of those.
In fact, we could probably even get rid of FLTL..FLTRND and just have a FLT instruction that clears the DIR bit.
Comments
I agree that getting the P2 out should be the top priority, but I think it would also be beneficial to hash out some of the points raised for the new Spin interpreter/compiler as well, particularly for the PASM compiler. One of the things this discussion brought to mind was that the early asm compilers went from having the programmer specify the addressing modes to having the compiler select the optimum mode automatically. Perhaps that could be done for PASM as well.
Chip has already made adjustments to the Verilog based on what he's done so far for the new Spin, and there may be more. This is part of the process he wants to do, so lets help support it instead of telling him to do something else.
They need the software ready for launch in order to be able to actually sell it. Spending a pile of money on a chip right now, that they then have to sit on for months while software is made is bad for business. Doing the "quick" path as some of you have suggested is a bad first impression, and likely to result in less return. They need good, cross platform, software support for the P2 in order to sell it.
Also, most of us are not the primary target audience. We can deal with a P2 that doesn't have finished software. Parallax targets education first, after that commercial users (a few of you included), then hobbyists. Most of there target audience won't even look at it without the finished software support.
For address operands, constant is the defaullt and * specifies a register.
That's a simple syntax that does the job.
And, 99-100% of the time I use these statement in the way that needs a "#".
For me, I'd rather stick to the existing syntax and have the compiler give a warning if these commands are used without the "#".
Warnings don't need to be obnoxious, you could have to use the menu to see them or something.
Just something one could check if don't understand what's wrong...
We can tell people it's about the instriction intent then?
Jmp is address, program flow. Mov is values, data manipulation, for example.
COGS are register to register design for most operations. That warrants the syntax we've got. A carve out for the other case makes sense.
I feel now no matter what we do, people will make the mistake. A jmp loads the PC, different from most instructions. That implied destination is where all the disconnects are.
We communicate that and no actual changes are needed!
If we make the change, and I don't care as long as it's limited to the odd cases, then it can help to communicate that, which your syntax does.
Given HUBEXEC basically turns the whole COG into registers, and that people can mix, we should make a doc on addressing forms.
Maybe I'll start on that when the syntax is sorted.
I know I got tripped up on jmp a whole lot less when I realized the target is an unaddressed register, as opposed to basically everything else being register to register.
It would be nice to agree on how we talk about these too.
To me, mov r1, #r2
R1 = absolute cog address
#r2 = immediate, some say literal here
Move works with values as the intent or target. Register to register explains why we dont ever have an immediate, or literal in the destination field. That would make no real sense.
In the source field, if we say "target source", and or say that is a value, it will all click. We want either the value contained in cog memory at an address, or we supply the value directly in the instruction. #
For jmp, it works with addresses, and the destination is implied, which I think should be the name of this addressing form.
Jmp r1
Jmp *r1
With the new syntax, we also have a name for the addressing mode. The implied destination makes sense now, and we either want an address value to load the PC with (r1), or we want the value contained in the cog memory at the address indicated by value to be loaded into the PC. (*r1)
These could be called implied indirect (*r1), and implied (r1)
My .02. How we say this matters, and its worth it so the majority of input cases are simple (mov r1, r2)
Then, mov r1, r2 and jmp r1 are differentiated by one vs two operands.
One operand is implied destination, two is explicit destination.
We then can list the modes and have it make a lot of sense.
There are only a few. And we then can talk about indexing, the instruction modify ALT and how it gets indexing and whatever else done.
Etc...
Thoughts?
Sounds all good to me.
Can you give some code examples to show the new syntax, in all cases ?
(including pre/post inc, where they exist )
Do the examples ozpropdev gave above change ?
Sure, why not, if it is a simple alias.
With finite passes, there are limits to how well this 'auto' works, so having both covers all practical uses.
-Phil
I much prefer just picking a syntax and adhering to it strictly, optional syntax leads to problems down the line.
It all boils down to what an implied destination, the PC, really means.
It means, a value is an address, because the implied destination uses it as an address.
Jmp written as "mov PC, r1" or "mov PC, #r1" works just fine with the existing syntax, as an example. The immediate, or literal # is the value assigned to the label address, and its a value that goes into the PC, which treats it as an address.
"For non-address operands, register is the default and # specifies a constant..
For address operands, constant is the default and * specifies a register.
That's a simple syntax that does the job. "
Seems that gives the cleanest code.
P1 was rather unusual in that register space was entirely code space, and only absolute opcodes existed.
In P2 the concept of relocatable labels as code space addresses, and relative opcodes makes it more like 'normal/other' microcontrollers.
A Label in P2, no longer always has a register alias.
In the HUBEXEC space, its more like, but still pretty different.
A mov will do register to register in COG, not memory to memory. Wrbyte and friends are needed for that, and people still need to think through what that means.
Looks similar, but does work differently.
It is also common in MCUs that Data memory access has less choices the 'further away' it is.
My point did not mention move, only code space labels.
Use "=" instead of ":="
Use "{...}" instead of white space block delimiting.
Method/object references that can be passed around.
Introduce structures.
Inheritance.
Types: byte, world, long (signed an unsigned of course), float, method, object, whatever.
As I have said before, at some point this is recreating C++ !
Anyway, the point of my post, it reminded me of this humorous old skit about "fixing" the obvious spelling and grammatical inconsistencies in the English language:
"English in the Future
Directors at Daimler Benz and Chrysler have announced an agreement to adopt English as the preferred language for communications, rather than German, which was another possibility.
As part of the negotiations, directors at Chrysler conceded that English spelling has some room for improvement and have accepted a five-year phase-in plan. In the first year, "s" will be used instead of the soft "c". Also, the hard "c" will be replased with "k". Not only will this klear up konfusion, but komputers have one less letter.
There will be growing kompany enthusiasm in the sekond year when the troublesome "ph" will be replased by "f". This will make words like "fotograf" 20 persent shorter.
In the third year, DaimlerKhrysler akseptanse of the new spelling kan be expekted to reash the stage where more komplikated shanges are possible.
DaimlerKhrysler will enkourage the removal of double letters, whish have always ben a deterent to akurate speling. Also, al wil agre that the horible mes of silent "e"'s in the languag is disgrasful, and they would go.
By the fourth year, peopl wil be reseptiv to steps sush as replasing "th" with "z" and "w" by "v".
During ze fifz year, ze unesesary "o" kan be droped from vords kontaining "o", and similar shanges vud of kors be aplid to ozer kombinations of leters.
After zis fifz yer, ve vil hav a reli sensibl riten styl. Zer vil be no mor trubls or difikultis, and employes vil find it ezi to kommunikat viz eash ozer.
Ov kors al supliers vil be expekted to us zis for all busines komunikation via DaimlerKhrysler.
Ze drem vil finali kum tru."
Most ASM manuals would instead use a clearer
mov r1, #Immed
and
Label:
jmp Label
or some variant of
jmp $-2
for relative
and jmp @Rn or jmp [Rn] or jmp *Rn for register-indirect cases.
Care is usually taken to use Rn only when the element really is a register, not an Immed or Label.
-Phil
LOL, a good idea taken a bit too far....as usual.
Of course Chip makes the final call! Considering the nature of the folks on this forum I would expect that his choices would not be far from what the majority votes for.
I understand that Chip is concerned that the Spin interpreter might uncover something that is needed in the silicon. So why not just extend the P1 Spin interpreter with P2-specific intrinsics instead of contemplating such huge changes. And if software support is so important at launch time why hasn't there been an effort to get GCC working on the P2? For the P2, I think C will be just as important as Spin.
I think it will largely be parallel - I don't see anyone advocating Silicon delay until release-quality software is done.
I'd agree the focus should be on software test coverage, and faster-to-test pathways have appeal there.
The critical silicon area in byte-code engines, is the inner-most loops, and that does not take long to prove and tune.
(I'd also like to see this tested/tuned for XIP from parts like QuadSPIx2 and HyperFLASH)
Spin2cpp seems to already have a working P2 pathway ?
.. and of course Tachyon has P2 pathways - has Peter tried the new byte-opcode opcodes. on his byte/word engine ?
EEEE 1101011 CZL DDDDDDDDD 001000000 DIRL {#}D {WC,WZ} DIR bit of pin D[5:0] = 0, C/!Z = IN bit. EEEE 1101011 CZL DDDDDDDDD 001000001 DIRH {#}D {WC,WZ} DIR bit of pin D[5:0] = 1, C/!Z = IN bit. EEEE 1101011 CZL DDDDDDDDD 001000010 DIRC {#}D {WC,WZ} DIR bit of pin D[5:0] = C, C/!Z = IN bit. EEEE 1101011 CZL DDDDDDDDD 001000011 DIRNC {#}D {WC,WZ} DIR bit of pin D[5:0] = !C, C/!Z = IN bit. EEEE 1101011 CZL DDDDDDDDD 001000100 DIRZ {#}D {WC,WZ} DIR bit of pin D[5:0] = Z, C/!Z = IN bit. EEEE 1101011 CZL DDDDDDDDD 001000101 DIRNZ {#}D {WC,WZ} DIR bit of pin D[5:0] = !Z, C/!Z = IN bit. EEEE 1101011 CZL DDDDDDDDD 001000110 DIRN {#}D {WC,WZ} DIR bit of pin D[5:0] = !bit, C/!Z = IN bit. EEEE 1101011 CZL DDDDDDDDD 001000111 TESTNIN {#}D {WC,WZ} Test !IN bit of pin D[5:0], !C/Z = IN bit. EEEE 1101011 CZL DDDDDDDDD 001001000 OUTL {#}D {WC,WZ} OUT bit of pin D[5:0] = 0, C/!Z = IN bit. EEEE 1101011 CZL DDDDDDDDD 001001001 OUTH {#}D {WC,WZ} OUT bit of pin D[5:0] = 1, C/!Z = IN bit. EEEE 1101011 CZL DDDDDDDDD 001001010 OUTC {#}D {WC,WZ} OUT bit of pin D[5:0] = C, C/!Z = IN bit. EEEE 1101011 CZL DDDDDDDDD 001001011 OUTNC {#}D {WC,WZ} OUT bit of pin D[5:0] = !C, C/!Z = IN bit. EEEE 1101011 CZL DDDDDDDDD 001001100 OUTZ {#}D {WC,WZ} OUT bit of pin D[5:0] = Z, C/!Z = IN bit. EEEE 1101011 CZL DDDDDDDDD 001001101 OUTNZ {#}D {WC,WZ} OUT bit of pin D[5:0] = !Z, C/!Z = IN bit. EEEE 1101011 CZL DDDDDDDDD 001001110 OUTN {#}D {WC,WZ} OUT bit of pin D[5:0] = !bit, C/!Z = IN bit. EEEE 1101011 CZL DDDDDDDDD 001001111 TESTIN {#}D {WC,WZ} Test IN bit of pin D[5:0], C/!Z = IN bit. EEEE 1101011 CZL DDDDDDDDD 001010000 FLTL {#}D {WC,WZ} OUT bit of pin D[5:0] = 0, DIR bit = 0, C/!Z = IN bit. EEEE 1101011 CZL DDDDDDDDD 001010001 FLTH {#}D {WC,WZ} OUT bit of pin D[5:0] = 1, DIR bit = 0, C/!Z = IN bit. EEEE 1101011 CZL DDDDDDDDD 001010010 FLTC {#}D {WC,WZ} OUT bit of pin D[5:0] = C, DIR bit = 0, C/!Z = IN bit. EEEE 1101011 CZL DDDDDDDDD 001010011 FLTNC {#}D {WC,WZ} OUT bit of pin D[5:0] = !C, DIR bit = 0, C/!Z = IN bit. EEEE 1101011 CZL DDDDDDDDD 001010100 FLTZ {#}D {WC,WZ} OUT bit of pin D[5:0] = Z, DIR bit = 0, C/!Z = IN bit. EEEE 1101011 CZL DDDDDDDDD 001010101 FLTNZ {#}D {WC,WZ} OUT bit of pin D[5:0] = !Z, DIR bit = 0, C/!Z = IN bit. EEEE 1101011 CZL DDDDDDDDD 001010110 FLTN {#}D {WC,WZ} OUT bit of pin D[5:0] = !bit, DIR bit = 0, C/!Z = IN bit. EEEE 1101011 CZL DDDDDDDDD 001010111 FLTRND {#}D {WC,WZ} OUT bit of pin D[5:0] = RND, DIR bit = 0, C/!Z = IN bit. (will be in v16) EEEE 1101011 CZL DDDDDDDDD 001011000 DRVL {#}D {WC,WZ} OUT bit of pin D[5:0] = 0, DIR bit = 1, C/!Z = IN bit. EEEE 1101011 CZL DDDDDDDDD 001011001 DRVH {#}D {WC,WZ} OUT bit of pin D[5:0] = 1, DIR bit = 1, C/!Z = IN bit. EEEE 1101011 CZL DDDDDDDDD 001011010 DRVC {#}D {WC,WZ} OUT bit of pin D[5:0] = C, DIR bit = 1, C/!Z = IN bit. EEEE 1101011 CZL DDDDDDDDD 001011011 DRVNC {#}D {WC,WZ} OUT bit of pin D[5:0] = !C, DIR bit = 1, C/!Z = IN bit. EEEE 1101011 CZL DDDDDDDDD 001011100 DRVZ {#}D {WC,WZ} OUT bit of pin D[5:0] = Z, DIR bit = 1, C/!Z = IN bit. EEEE 1101011 CZL DDDDDDDDD 001011101 DRVNZ {#}D {WC,WZ} OUT bit of pin D[5:0] = !Z, DIR bit = 1, C/!Z = IN bit. EEEE 1101011 CZL DDDDDDDDD 001011110 DRVN {#}D {WC,WZ} OUT bit of pin D[5:0] = !bit, DIR bit = 1, C/!Z = IN bit. EEEE 1101011 CZL DDDDDDDDD 001011111 DRVRND {#}D {WC,WZ} OUT bit of pin D[5:0] = RND, DIR bit = 1, C/!Z = IN bit. (will be in v16)I'm thinking we could get by with just FLTL..DRVRND and ditch DIRL..TESTIN. This would lighten the logic a bit.
It would mean that all DIR/OUT instructions would always affect a DIR bit and an OUT bit. The IN would always be reported back via C. Can you think of a case where DIRL..TESTIN is really necessary? It's looking to me like we could get rid of those.
In fact, we could probably even get rid of FLTL..FLTRND and just have a FLT instruction that clears the DIR bit.