Opps, I see. It was all nulls so wasn't printing until the valid data came through. Fool myself.
Thanks for testing that, Evanh. My first impression on reading your initial post was that D[31] + RDFAST was waiting, afterall. Then I remembered testing it for no-wait and it worked okay.
If you repeat those measurements for 1.5V Core Voltage, what do they look like ? (including Quiescent power numbers )
Not everyone wants 180+ MHz, and it may be that a 100+MHz part that runs at lower power at 1.5V than 1.8V is a better fit for some designs ?
The Cpd formula predicts appx (100MHz)
Vcc = 1.8 Pd = Cpd * Vcc^2 * Fi Pd = 518mW
Vcc = 1.5 Pd = Cpd * Vcc^2 * Fi Pd = 360mW
I have no idea about the Plan 9 C compiler but if it runs on the PicoRV32, which has no memory management and such heavy weight OS stuff, it sounds promising.
Back in the day BDSC could compile C code on a 64K Z80 machine running CP/M. (Still the first and only C compiler to actually run on a Propeller chip by the way)
Given the vastly bigger memory space of the P2 a self-hosting C compiler should be possible.
I have no idea about the Plan 9 C compiler but if it runs on the PicoRV32, which has no memory management and such heavy weight OS stuff, it sounds promising.
Back in the day BDSC could compile C code on a 64K Z80 machine running CP/M. (Still the first and only C compiler to actually run on a Propeller chip by the way)
Given the vastly bigger memory space of the P2 a self-hosting C compiler should be possible.
This is one problem with doing work on a C compiler for the P2. Lots of people want to go in lots of directions. We have p2gcc already and there is talk of a GCC or an LLVM backend. Now we're talking about a port of the Plan 9 C compiler. We have people who are happy to have PC-based tools and those who want a self-hosted development environment. We don't even have a very large community here but even that small community is hopelessly splintered. I'm afraid none of these efforts (except maybe p2gcc) are going to succeed because none have enough resources with all of the other projects going on.
I wonder how hard it would be to target P2? And run on P2.
KeithE/Heater/David, I would support this 100% with love and effort. I know a few wizards in the plan9 community who had an interest in the P1 years ago who I could reach out to for help.
In case others here are curious, the plan9 compilers favor simplicity of implementation over optimizations. In fact the Go language community leveraged this compiler family early in that language's development (I haven't kept up with the state-of-that-art).
During my TurboPascal and TurboC days, when those compilers couldn't generate optimal code, we just used the asm keyword to insert x86 code. I'd favor that to be honest.
Quite honestly, I've avoided the whole GCC thing here because after "porting" it to a couple of architectures back in the late 90's, there's no way I'd subject myself to that complexity again.
On the other hand, non-GCC might cause others grief here... from my point of view, if we had a nice front end, ala the Arduino multi-platform front-end, 75% of the users wouldn't care as long as there was a smooth path from code-example to code-execution.
While I'm on this rant, I saw that the TI430 community has their Arduino development environment (https://energia.nu) that leverages on that community's work (has GCC behind the scenes).
This is one problem with doing work on a C compiler for the P2. Lots of people want to go in lots of directions. We have p2gcc already and there is talk of a GCC or an LLVM backend. Now we're talking about a port of the Plan 9 C compiler. We have people who are happy to have PC-based tools and those who want a self-hosted development environment. We don't even have a very large community here but even that small community is hopelessly splintered. I'm afraid none of these efforts (except maybe p2gcc) are going to succeed because none have enough resources with all of the other projects going on.
That's true, but this is early research stages, and simpler has the appeal it is easier to actually do the port.
KeithE/Heater/David, I would support this 100% with love and effort. I know a few wizards in the plan9 community who had an interest in the P1 years ago who I could reach out to for help.
In case others here are curious, the plan9 compilers favor simplicity of implementation over optimizations. In fact the Go language community leveraged this compiler family early in that language's development (I haven't kept up with the state-of-that-art).
During my TurboPascal and TurboC days, when those compilers couldn't generate optimal code, we just used the asm keyword to insert x86 code. I'd favor that to be honest.
Quite honestly, I've avoided the whole GCC thing here because after "porting" it to a couple of architectures back in the late 90's, there's no way I'd subject myself to that complexity again.
Are there any pages/links of current plan9 activity and active ports ?
Which C standards does to comply with ?
This is one problem with doing work on a C compiler for the P2. Lots of people want to go in lots of directions. We have p2gcc already and there is talk of a GCC or an LLVM backend. Now we're talking about a port of the Plan 9 C compiler
Yes, wouldn't it be great if we could harness all the Propeller heads to do the one true thing? Whatever that is.
It's in the nature of Propeller heads, and humans in general, that this is no so easy.
Which I would say is a good thing in some way. It gave us the Catalina and ImageCraft compilers. It gave us BST and HomeSpun. Back in the day it gave us propasm by Clif Biffle.
At the end of the day everyone has different skill sets and different passions that drive them.
Me, I'm just an observer of all this. Happy that I got some emulators running on the P1 that enabled using real compilers.
This is one problem with doing work on a C compiler for the P2. Lots of people want to go in lots of directions. We have p2gcc already and there is talk of a GCC or an LLVM backend. Now we're talking about a port of the Plan 9 C compiler
Yes, wouldn't it be great if we could harness all the Propeller heads to do the one true thing? Whatever that is.
It's in the nature of Propeller heads, and humans in general, that this is no so easy.
Which I would say is a good thing in some way. It gave us the Catalina and ImageCraft compilers. It gave us BST and HomeSpun. Back in the day it gave us propasm by Clif Biffle.
At the end of the day everyone has different skill sets and different passions that drive them.
Me, I'm just an observer of all this. Happy that I got some emulators running on the P1 that enabled using real compilers.
Let's see, RossH who wrote Catalina is gone and so it is now unsupported, ImageCraft abandoned their Propeller offering. BST has been abandoned as has HomeSpun I believe. Even PropGCC has stagnated. Is this what we want again?
I don't know if the PropGCC development was contributed back, but the *secret* to keeping stuff relevant is to contribute it upstream to the main project. If there is an LLVM port, then that port needs to be contributed back to LLVM so it's not just a pet project of 1 person.
I've seen the results of forks in the past, they never survive reliably and just end up being much harder to maintain as the core arch of the forked project changes.
I've never used/tinkered with LLVM, but I've heard lots of good things about it. I see it as the BSD of compilers as GCC is the Linux of compilers.
You can be certain that if I get MicroPython working, I'll be issuing pull requests to their Git repo.
Arithmetic manipulation between mixes of signed
and unsigned may simulate and synthesize in unintended
ways
I dream of having to deal with that... no I don't. It may be because of such things that the VHDL crowd seems so keen of the strong types in VHDL. No sarcasm here. I just wonder... I don't know the matter deep enough to judge.
That is the sort of reason I'm getting into SpinalHDL for logic design. Being based on the Scala language Spinal is very fussy about types and all kind of other checks that can catch one out in Verilog. Besides it's generally a much higher level and nicer language than Verilog. Spinal generates Verilog or VHDL code so it's easy to check that you get what you order.
I just did a test to determine if my limited use of '$signed' caused the problem in the modulator.
It did.
Altera's Quartus II Verilog compiler sign-extends any term within a $signed() construct, whereas the ASIC Verilog compiler only honors $signed() if all other terms on the right-hand part of the equation are also of signed type.
This caused the modulator to not work right.
I checked all my Verilog source files for use of '$signed()' where I involved another term which was not signed, which would cause errant results. I found three things:
1) The colorspace modulator is broken (as observed).
2) The ALTSN..ALTB instructions don't sign-extend S[17:09] before adding it into D.
3) The smart pin measurement modes that are supposed to count +1/-1 can only count +1/+3.
These are all simple to remedy at the Verilog level, but will require a respin to fix.
I checked all my Verilog source files for use of '$signed()' where I involved another term which was not signed, which would cause errant results. I found three things:
Should you just remove all uses of '$signed()', even if some uses appear to follow some rules ? Just seems a high risk item, best avoided entirely...
I checked all my Verilog source files for use of '$signed()' where I involved another term which was not signed, which would cause errant results. I found three things:
Should you just remove all uses of '$signed()', even if some uses appear to follow some rules ? Just seems a high risk item, best avoided entirely...
Comments
Not that I have got that far yet...
Good point. That should be documented.
It's going to be the same as RD/WRLONG, plus one clock for each extra long, barring any priority interruptions from the streamer.
Thanks for testing that, Evanh. My first impression on reading your initial post was that D[31] + RDFAST was waiting, afterall. Then I remembered testing it for no-wait and it worked okay.
“Richard Miller tells us we can use the Plan 9 C compiler instead of GCC or LLVM #ORConf“
To which Clifford replied:
“It even runs on PicoRV32!
https://orconf.org/#plan9
I wonder how hard it would be to target P2? And run on P2.
If you repeat those measurements for 1.5V Core Voltage, what do they look like ? (including Quiescent power numbers )
Not everyone wants 180+ MHz, and it may be that a 100+MHz part that runs at lower power at 1.5V than 1.8V is a better fit for some designs ?
The Cpd formula predicts appx (100MHz)
Vcc = 1.8 Pd = Cpd * Vcc^2 * Fi Pd = 518mW
Vcc = 1.5 Pd = Cpd * Vcc^2 * Fi Pd = 360mW
I have no idea about the Plan 9 C compiler but if it runs on the PicoRV32, which has no memory management and such heavy weight OS stuff, it sounds promising.
Back in the day BDSC could compile C code on a 64K Z80 machine running CP/M. (Still the first and only C compiler to actually run on a Propeller chip by the way)
Given the vastly bigger memory space of the P2 a self-hosting C compiler should be possible.
KeithE/Heater/David, I would support this 100% with love and effort. I know a few wizards in the plan9 community who had an interest in the P1 years ago who I could reach out to for help.
In case others here are curious, the plan9 compilers favor simplicity of implementation over optimizations. In fact the Go language community leveraged this compiler family early in that language's development (I haven't kept up with the state-of-that-art).
During my TurboPascal and TurboC days, when those compilers couldn't generate optimal code, we just used the asm keyword to insert x86 code. I'd favor that to be honest.
Quite honestly, I've avoided the whole GCC thing here because after "porting" it to a couple of architectures back in the late 90's, there's no way I'd subject myself to that complexity again.
On the other hand, non-GCC might cause others grief here... from my point of view, if we had a nice front end, ala the Arduino multi-platform front-end, 75% of the users wouldn't care as long as there was a smooth path from code-example to code-execution.
While I'm on this rant, I saw that the TI430 community has their Arduino development environment (https://energia.nu) that leverages on that community's work (has GCC behind the scenes).
That's true, but this is early research stages, and simpler has the appeal it is easier to actually do the port.
Are there any pages/links of current plan9 activity and active ports ?
Which C standards does to comply with ?
It's in the nature of Propeller heads, and humans in general, that this is no so easy.
Which I would say is a good thing in some way. It gave us the Catalina and ImageCraft compilers. It gave us BST and HomeSpun. Back in the day it gave us propasm by Clif Biffle.
At the end of the day everyone has different skill sets and different passions that drive them.
Me, I'm just an observer of all this. Happy that I got some emulators running on the P1 that enabled using real compilers.
Maybe this language diversion, should go into its own thread, so as to not confuse the new-p2-silicon-observations thread ?
I'll leave this here:
https://9p.io/sys/doc/compiler.html
You might recognize the author.
I have no idea what those guys are up to now. Clearly their propeller heads took them off to other realms.
Sounds like we still have some skillful Propeller enthusiasts on board though.
I hear that new guys on the block want to get MicroPython running on the P2.
Hmm...except that will require a C compiler...
Seconded, there are a number of existing threads for C-related discussions. Please use those, not this.
+1 YES - why can't we self-regulate ourselves when we see we are going OT and cluttering the thread?
I've seen the results of forks in the past, they never survive reliably and just end up being much harder to maintain as the core arch of the forked project changes.
I've never used/tinkered with LLVM, but I've heard lots of good things about it. I see it as the BSD of compilers as GCC is the Linux of compilers.
You can be certain that if I get MicroPython working, I'll be issuing pull requests to their Git repo.
I dream of having to deal with that... no I don't. It may be because of such things that the VHDL crowd seems so keen of the strong types in VHDL. No sarcasm here. I just wonder... I don't know the matter deep enough to judge.
It did.
Altera's Quartus II Verilog compiler sign-extends any term within a $signed() construct, whereas the ASIC Verilog compiler only honors $signed() if all other terms on the right-hand part of the equation are also of signed type.
This caused the modulator to not work right.
I checked all my Verilog source files for use of '$signed()' where I involved another term which was not signed, which would cause errant results. I found three things:
1) The colorspace modulator is broken (as observed).
2) The ALTSN..ALTB instructions don't sign-extend S[17:09] before adding it into D.
3) The smart pin measurement modes that are supposed to count +1/-1 can only count +1/+3.
These are all simple to remedy at the Verilog level, but will require a respin to fix.
Glad to hear the problem is identified.
Fix this and the P59 thing and we're golden...
That's only one problem identified, on the use of $signed.
There may be many others still to find.... - ie more may need to be fixed yet.
The errata is growing, but the chips are still looking useful engineering samples.
Should you just remove all uses of '$signed()', even if some uses appear to follow some rules ? Just seems a high risk item, best avoided entirely...
Does that mean Quadrature counting is broken ? What other modes are affected ?
What about live-clear-on-read ? I think that just loads 0 or +1 ?
I would like to buy a board with a P2 mounted on it. So that I can write assembler programs that I can upload to the obex.
HydraHacker
Fortunately, the Goertzel stuff seems to all be okay. I am going to test it tonight to be sure, though.
I agree.
"$signed()" worked where I used it amid other signed values. I think it is okay.
Smart pin quadrature counting is broken! The other affected modes are the INC/DEC modes. Modes that just INC and reload 0 on read are unaffected.