More info about how a Xoro34 instruction might work. In effect it's Xoro32+2, where the 32 are D[31:0] and the 2 are C,Z with new internal signals xoro_c and xoro_z.
wcz is mandatory and a spare opcode bit allows for two variants, as explained below.
XORO32 is pretty easy to use and that simplicity should be kept in XORO34 as far as possible. In particular, saving and restoring the flags between iterations, if wanted for other purposes, could be avoided by storing xoro_c and xoro_z in a 2-bit register. After cog startup xoro_c = 0 (or 1) and xoro_z = 1, so that any value of D could be used as the initial seed including zero.
XORO34 D,0 or plain XORO34 D writes D[31:0] and reads D[31:0],C,Z but does not write xoro_c and xoro_z. XORO34 D,1 forces xoro_c and xoro_z to the startup values of 0 (or 1) and 1, respectively, but is otherwise the same.
Only XORO34 D is necessary for testing. It could be used for re-seeding, too, by iterating until C,Z are some desired value. This way a previous sequence could always be re-generated. In other words, an instruction variant that explicitly writes xoro_c and xoro_z could be omitted.
Are the three XORO34 candidates "full period"?
If so, I'm really keen to know how Xoro34_sum[15:1] perform.
Yes, everything in the score tables is full period. I'm about to run the whole quality suite for s17 ...
correction, it was done already but I hadn't bothered to post it:
Variant Key:
- "Word1" is the full summed word size minus the lsb, for s17 (Xoroshiro34+) that is the top 16 bits [16:1].
- "Word2" is the full summed word size minus two lsb, for s17 that is the top 15 bits [16:2].
- "Byte09" is the most significant 8 bits of the summed word, for s17 that is bits [16:9]. Label changes per position.
- "Byte04" is half way down the summed word, for s17 that is bits [11:4]. Label changes per position.
- "Byte2" is always bits [9:2] for all word sizes.
- "Byte1" is always bits [8:1] for all word sizes.
- "Bit" is msb.
Tony,
How and where is C and Z being stored and retrieved between state iterations? What I mean is the current XORO32 method is 100% held by the D register, and can be iterated without concern for other uses of C and Z.
Tony,
How and where is C and Z being stored and retrieved between state iterations? What I mean is the current XORO32 method is 100% held by the D register, and can be iterated without concern for other uses of C and Z.
It's explained above but to recap I think the best way is to have a 2-bit register in hardware that stores signals I call xoro_c & xoro_z, which are the LSBs of the two 17-bit words.
The XORO34 D instruction reads the current state from D[31:0], xoro_c & xoro_z, then the xor and shift logic does it stuff, then the new state is written back to D[31:0], xoro_c & xoro_z. At the same time xoro_c is copied to C and xoro_z copied to Z.
The high 17-bit word of the new state returned is {D[31:16],C} and the low 17-bit word is {D[15:0],Z}. D[31:16] and D[15:0] are summed as now and the result incremented if C & Z (a condition which I call 'overflow' ).
C and Z get overwritten by XORO34 D but once summing is complete C and Z can be used for other things until the next XORO34 D. The only outstanding issue is how to set xoro_c & xoro_z to some known state during seeding.
The instruction encoding allows for two variants, one that never writes to xoro_c & xoro_z and one that does. The latter might not be strictly necessary but would make programming simpler. It could just write C to xoro_c and Z to xoro_z but that would mean setting the flags to known values.
I thought it better to write fixed values to xoro_c & xoro_z, at least one of which must be 1, with D providing the variable seed (D = 0 now permitted). 2^32 different seed values should be ample and 2^34-1 is probably overkill.
Ah, dedicated shadow like flags for C/Z that are initially seeded under the right conditions. It means only a single PRNG can be operating on each Cog using this instruction. The current method can have many running concurrently.
On reflection, users need the option of being in total control and therefore it is best if C and Z are state inputs in one of the two variants:
XORO34 D,0 wcz 'input state is D[31:0], xoro_c, xoro_z
XORO34 D,1 wcz 'input state is D[31:0], C, Z
Second variant could be the only one, in which case 2-bit hardware register not required and C & Z could be stored in a second state register if necessary using software, e.g. RCZR/RCZL which look ideal for the job.
This change of mind means number of different seeds is 2^34-1.
Summary
16 bits of high-quality pseudo-random data could be achieved on the P2 using the xoroshiro34+ algorithm.
Second variant could be the only one, in which case 2-bit hardware register not required and C & Z could be stored in a second state register if necessary using software, e.g. RCZR/RCZL which look ideal for the job.
You know what, this now begs to be a Xoroshiro64+, with a 31 bit summing result.
I'd have to learn how to make the iteration skipping algorithm to be able to come up with the list of full period candidates.
I slept on that thought last night and think it's probably not too hard to use it either. It won't be possible to skip the whole full period in a single hop though, because the skips are in powers of two so would skip just past the full period step.
Not only that but feeding PractRand is done in bytes anyway, so I'm repacking the output to suit that. For example, the "bit" variant does eight iterations/samples before handing a byte of data over to PractRand. The WordX samples are a tad mind bending to repack because there is continuous dangling data.
Also, you can see the comparative impact in the score tables. WordX and the ByteX variants are much of a muchness. There are exceptions of course, but those will have reasons other than a difference in data packing sizes.
That said, I still look for the scores that have WordX scores higher than ByteX scores, but the expected ratio is only 2:1 - which I feel, given PractRands sensitivity, isn't much more than the noise floor.
And reshuffling the bit order with a fixed shuffle pattern does nothing for quality.
EDIT: This statement has an interesting twist, since PRNGs do use a fixed bit twiddle (shuffle/invert/insert) as a feature of their algorithm. What makes a modern PRNG function at all, however, is the heavy dependence on the XOR merging of multiple patterns. The bit positions that get flipped are dynamic, based on prior state.
Further thoughts on RCZR & RCZL. They are interesting instructions that allow a register to act as a flag FIFO or LIFO/stack.
For example, flags from one XORO34 PRNG could be saved and those for a second PRNG restored in one instruction, then PRNG2 flags saved and PRNG3 flags restored together, etc. If less than 16 PRNGs a shift would be needed after the last one to align the flags properly ready for the next set of iterations.
The drawback with RCZR & RCZL is they are sequential. Imagine if any register could hold 16 copies of the flags, with random access for both reading and writing in a single instruction. All flag worries would disappear. Something for the P3 perhaps?
Let's call this hypothetical instruction FLAGS. Apart from D, it would need an 8-bit operand to specify separate 4-bit read and write addresses of the CZ pairs within D. FLAGS could fit into one of the empty D,S instruction slots near the bottom of the opcode map.
You know @TonyB, that you are quite late to the party?
The buffet was open about 3 years ago, most of the partygoers left last year, all drinks are drunken, the party is over.
The hosts are cleaning the house and it is simply the wrong time to open just another bottle of champagne.
Even Colombo stopped asking 'just one more question'. If Parallax want to survive they have to act.
A lot of good people went away after years of 'just one more thing' and ARM, Arduino & co took over. Its not just me @Peter J. mentioned it too.
The forum shows it clearly
No new discussions about projects somebody does with a P1, one lonely BasicStamp project. Instead we have electric cars, computer history, Cassini, Ravioli, FPGA and RISC-V discussions. Interesting discussions, but a sign that something is wrong, compared to say 1-2-3 years ago.
Meanwhile are the Dev-Tools stagnant, no new PropTool, no new Gcc, no new SipleIDE/PropellerIDE, everything and everybody is waiting for the wonders of the P2, being JUST around the corner since YEARS.
But nothing goes forward as long as there is no instruction freeze. And at least some test chips.
And then - hopefully - Parallax can update their Dev-Tools and Documentation.
And IF then - hopefully - some users are left to do something with the P2, it might be interesting again for makers to make something with it, post and discuss about it.
The Spin Group is frustrated that new products do not have Spin Example anymore and the PropTool neither uses Openspin nor supports the WiFy loader of SimpleIDE, the C Group is frustrated because even if they update Gcc, SimpleIDE will install and use the 3 year old version.
The MAC user getting frustrated because somehow you can't upload 32k-binaries anymore and BasicStamp users can't get their Boards loading at all. And nobody seems to be able to fix that.
Because - since years - nothing gets done on the dev-tools, because P2 is just around the corner.
@Ken, hit a big win with Blockly, so the educational sector keeps everything running while slowly the fan base has been moving away to more reachable fruits.
And every time it is just one more thing, and then another one. Since years.
And still I read - just one more opcode change, just a couple of more registers to save C,Z, just change the prng to 34 bit, just...
this simply has to stop or the P2 will never exist.
This Prop2 project has eaten almost a quarter of my life, now. Or, much life has happened and many other opportunities to do different things have slipped away while this project has dragged on. I feel like I'm trapped in a bubble, as the world keeps changing and heading in a direction I don't even relate to. We are right at the end of this project, though. We're ready to pay OnSemi to build this chip. That is pressing forward at full force.
Here is where I feel lost and not confident: I really like the feeling of "owning" my work and the tools needed to get my work done. Things are trending where we don't seem to own anything and the tools we use to do our work can vanish in a snap, never mind that they are bloated beyond all prior imagination. This is a tenuous situation which I find pretty demoralizing. I don't want to vest my time into things that can just vanish due to an unpaid bill, or something. I wonder if others feel this way. Younger people seem to not even think about things like this.
This is what I want to do, personally: Make a tool system that can run on-chip, that contains a file manager, editor, compiler, and debugger. The whole thing would definitely be under 32KB. It wouldn't need any internet access, authentication, email account, license, maintenance fees, etc. It would just work and you would own it. Nobody could "disappear" it. It would be there years later, still working as it did originally. No magic "updates" would alter it in some unexpected and irreversible way. You could get "married" to it, so to speak. As long as there is a need to input and output analog and digital signals on a first-principles basis, I think there's also a need for a stable and reliable platform from which to operate. This is my Luddite pipe dream. I can't help but think that people would discover how nice (and vital) it is to have a stable base on which to develop things.
Chip,
While I agree with you that it is nice to own/control the whole enchilada, I really think our philosophy is disappearing quickly. I have pushed for a self-contained P1 development system, which I have done with pieces from others, there seems little interest in it.
FWIW...
Chips built with ~20nm or less only have an expected life of 10 years (min) due to trace migration.
There is of course a push for open software. While this is good for us, it's not practical for everything. Some software just needs to be done commercially. What company will be prepared to invest millions of dollars without financial returns.
This is what I want to do, personally: Make a tool system that can run on-chip, that contains a file manager, editor, compiler, and debugger. The whole thing would definitely be under 32KB. It wouldn't need any internet access, authentication, email account, license, maintenance fees, etc. It would just work and you would own it. Nobody could "disappear" it. It would be there years later, still working as it did originally. No magic "updates" would alter it in some unexpected and irreversible way. You could get "married" to it, so to speak. As long as there is a need to input and output analog and digital signals on a first-principles basis, I think there's also a need for a stable and reliable platform from which to operate. This is my Luddite pipe dream. I can't help but think that people would discover how nice (and vital) it is to have a stable base on which to develop things.
That's a reasonable long term goal, but probably not good for fastest P2 product ramp. The product needs to appeal to mainstream designers.
Yes, it is nice to be 'self contained' but development these days is not done in isolation.
What you describe is quite close to the TurboPascal IDE, but that ran on DOS, and DOS had no means to view PDFs
I can't really imagine development today, without PDF readers, and some web access.
The nearest modern equivalent I can think of is Project Oberon, and I think that is much larger than 32k, and still cannot view PDF or web browse ?
Users these days expect chips to support Compilers/Assemblers, and MANY languages.
That's too much to load into 'stand alone', which will always be constrained.
Better to focus on USABILITY things like
* faster downloads
* Compilers and interpreters for P2
* Boot and run from Quad and Octal Memory
* Start Debuger design
Chip
Maybe to start the ball rolling on the tool chain front, you could make a command line version of Pnit and let the lurkers on this forum play with it and create a IDE or two.
As I said a couple of times before Sphinx by @Mpark hooked me finally onto the propeller. I was in Heaven again.
Sure I am using PropTool mostly, but I do have a running Sphinx over serial just for short tests. And for fun. I envy @Peter J. and the tachyon folks, but sadly can't wrap my head around forth.
But the Sphinx Prop just works. since ~5(?) years? No updates, no hassle, running on a Protoboard with serial, so not even USB-driver needed.
This time things look even better, If @Bean is still alive when the P2 finally is there, then he can make C out of your Spin-compiler again and we can run it thru PropGcc and have a identical compiler on PC and Prop2.
Self hosting worked with the P1 and Sphinx up to say 25KB binaries, then memory of the P1 run out. Even smaller with VGA and PS2 Keyboard.
But I personally think your feeling of loss is more bound to the change in live it will bring to you to STOP working on the P2. At the time you 'delivered' the P1 you also had the point where you also did not own all the tools needed to produce it. Even now you do not really own Quartus or what it is called.
Like you I slowly start to hate all the changes done by Linux, Windows and whoever all the time on MY TOOLS so I have to rewrite all my projects again and again just because of a new hype of framework going away next year for another hype of another framework, OS or Gadget.
Sometimes I even consider to port all my work of the last 20 years back to COBOL on the backend, because the things I wrote '92 did still run on GnuCOBOL without modification as I tried last year, for fun.
I personally hope that the P2 will give me a long lasting simple personal computer, unaffected by Hype-changes and virulent malicious software. The resources are there to do it. And a nice new Multi-measurement device to check out other things. Also without mandatory updates, fees, malicious attacks from other entities.
Yes, I definitely see a lot of uses for a P2, where I failed to do so with a P1 because of running out of memory, pins or/and cogs.
My only wish would be to have the monitor back from the P2-Hot, but if typing constant enough one could program it in via serial terminal.
Mike, that's what I want, too: a long-lasting personal computer that just works, without any garbage going on. I think if people could get a taste of that, they would really like it.
One point with the P1 is that it has no configuration registers, Pin allocations by function and all the other garbage.
Just a block of RAM and you as a programmer, can use almost all of it for your own program.
Same still is valid for the P2. OK, some Interrupt Vectors were added.
I read some documentation how to program bare metal on some older ARM-chip. Using Keil-something, quite nice actually.
After a while I gave up reading, because they simply lost me. English is my 3. language, so I failed to follow.
But P1 and P2 have a quite simple Hub-Ram/Image layout. Up and running in 2-5 Pages of documentation, not thousands.
So one can understand what the computer does and where what is stored. That's why I plead to bring the monitor back. Even if just copied at some position after startup and over-writable by any boot loader.
But available if not overwritten, or there if no boot-media is present.
Just connect any serial terminal and you have the most minimalistic self hosted development system. You can view/edit/execute/debug any part of hub-ram.
Sure, assembler/disassembler would be nice, but not needed. Monitor alone would be sufficient.
But, yes, one can type it in serial, with the current boot loader, like the DATA statements for Atari and Commodore in the printed magazines...
I hate all the updates to my pc software too. I never know...
How long will my pc be unusable while doing the update.
Lack of control for some updates.
How much data will it use because I am on "metered internet".
What is going to break afterward the update.
For example, last month I had a little over 3GB left in my Internet quota for the month. Windows 10 wanted to update, so I foolishly let it loose while I went out. Silly me!!!! Windows update downloaded over 9GB, so I went over my limit for the month by 6GB. This cost me $60 !!!
At least to date, I haven't found anything not working. But it's early days so far.
Comments
XORO32 encoding (existing)
XORO34 encoding (possible)
wcz is mandatory and a spare opcode bit allows for two variants, as explained below.
XORO32 is pretty easy to use and that simplicity should be kept in XORO34 as far as possible. In particular, saving and restoring the flags between iterations, if wanted for other purposes, could be avoided by storing xoro_c and xoro_z in a 2-bit register. After cog startup xoro_c = 0 (or 1) and xoro_z = 1, so that any value of D could be used as the initial seed including zero.
XORO34 D,0 or plain XORO34 D writes D[31:0] and reads D[31:0],C,Z but does not write xoro_c and xoro_z. XORO34 D,1 forces xoro_c and xoro_z to the startup values of 0 (or 1) and 1, respectively, but is otherwise the same.
Only XORO34 D is necessary for testing. It could be used for re-seeding, too, by iterating until C,Z are some desired value. This way a previous sequence could always be re-generated. In other words, an instruction variant that explicitly writes xoro_c and xoro_z could be omitted.
The initial state could be set to 0 in the PASM code in a previous post so that seed is 1 not 3:
http://forums.parallax.com/discussion/comment/1420257/#Comment_1420257
Apart from that no other changes required.
correction, it was done already but I hadn't bothered to post it:
Variant Key:
- "Word1" is the full summed word size minus the lsb, for s17 (Xoroshiro34+) that is the top 16 bits [16:1].
- "Word2" is the full summed word size minus two lsb, for s17 that is the top 15 bits [16:2].
- "Byte09" is the most significant 8 bits of the summed word, for s17 that is bits [16:9]. Label changes per position.
- "Byte04" is half way down the summed word, for s17 that is bits [11:4]. Label changes per position.
- "Byte2" is always bits [9:2] for all word sizes.
- "Byte1" is always bits [8:1] for all word sizes.
- "Bit" is msb.
Xoroshiro34+ PractRand Score Table Combination Word1 Word2 Byte09 Byte04 Byte2 Byte1 Bit ==================================================================== [ 1 1 2] 128K 128K 32K 32K 64K 64K 4G [ 1 1 8] 64K 512K 1M 4M 2M 1M 4G [ 1 3 6] 16M 32M 1M 2M 512K 512K 4G [ 1 4 12] 8M 32M 128M 8M 64K 64K 4G [ 1 5 7] 8M 16M 4M 2M 2M 1M 4G [ 1 6 3] 4M 16M 512K 512K 128K 128K 4G [ 1 7 2] 512K 2M 4M 128K 128K 64K 4G [ 1 10 1] 32K 64K 256K 16K 4K 4K 256M [ 1 10 13] 1M 2M 64K 64K 64K 64K 4G [ 1 11 13] 1M 2M 64K 64K 64K 128K 4G [ 1 12 12] 64K 64K 16K 32K 64K 64K 1M [ 1 16 1] 8K 16K 8K 4K 2K 4K 2G [ 1 16 3] 256K 256K 128K 128K 128K 64K 4G [ 2 1 1] 16K 16K 8K 8K 8K 8K 4K [ 2 2 2] 16K 64K 16K 16K 32K 16K 256M [ 2 5 7] 32M 64M 16M 8M 8M 16M 4G [ 2 6 13] 16M 32M 32M 128K 128K 128K 4G [ 2 7 1] 128K 256K 16M 32K 8K 16K 16M [ 2 7 9] 16M 32M 256M 64M 32M 128M 4G [ 2 8 6] 8M 32M 32M 8M 8M 2M 4G [ 2 10 2] 128K 512K 2M 64K 16K 16K 128M [ 2 10 13] 8M 8M 128K 128K 128K 256K 4G [ 2 12 12] 256K 512K 64K 128K 128K 256K 32M [ 2 14 12] 4M 8M 128K 128K 256K 256K 4G [ 2 16 2] 32K 64K 32K 16K 16K 32K 256M [ 3 1 7] 16M 32M 64M 32M 32M 32M 4G [ 3 1 8] 2M 64M 1G 128M 128M 128M 4G [ 3 1 10] 32M 32M 512K 1M 2G 128M 4G [ 3 2 13] 32M 16M 256K 128K 256K 256K 4G [ 3 4 10] 128M 512M 64M 32M 2G 128M 4G [ 3 6 1] 4M 16M 4M 256K 256K 128K 16M [ 3 13 12] 32M 16M 256K 256K 512K 512K 512M [ 3 14 3] 256K 512K 256K 128K 128K 128K 4G [ 3 16 1] 128K 256K 64K 64K 64K 64K 4G [ 3 16 9] 32M 32M 128M 1G 2G 128M 4G [ 3 16 12] 32M 16M 256K 256K 256K 1M 4G [ 4 4 4] 1M 2M 1M 256K 256K 256K 256M [ 4 4 10] 32M 64M 8M 8M 512M 128M 1G [ 4 5 7] 256M 1G 8M 8M 8M 16M 4G [ 4 8 16] 16M 32M 512M 512K 512K 512K 4G [ 4 14 15] 16M 32M 512K 512K 1M 1M 4G [ 5 5 8] 32M 64M 256M 128M 128M 128M 4G [ 5 6 15] 512M 512M 512M 16M 8M 8M 4G [ 5 12 5] 2M 2M 8M 2M 4M 8M 2G [ 5 15 14] 128M 128M 2M 2M 4M 16M 4G [ 5 16 5] 512K 512K 1M 512K 512K 512K 1G [ 6 1 8] 512M 2G 256M 256M 256M 128M 4G [ 6 1 16] 64M 64M 2M 2M 4M 8M 4G [ 6 3 1] 16M 16M 1M 1M 2M 2M 512K [ 6 5 14] 16M 16M 16M 16M 64M 128M 4G [ 6 6 6] 2M 2M 8M 512K 512K 256K 512M [ 6 8 2] 128M 512M 32M 1M 2M 2M 4G [ 6 8 6] 8M 32M 4M 512K 4M 1M 8M [ 6 8 10] 512M 4G 1G 64M 64M 128M 4G [ 6 12 7] 128M 512M 64M 64M 64M 64M 4G [ 6 14 6] 1M 1M 512K 8M 512K 512K 1G [ 7 1 3] 32M 128M 2M 2M 4M 4M 4M [ 7 1 13] 512M 1G 128M 256M 512M 128M 64M [ 7 4 7] 16M 16M 2M 4M 8M 16M 4G [ 7 5 1] 16M 16M 1M 1M 1M 2M 4M [ 7 5 2] 128M 128M 2M 2M 2M 4M 4M [ 7 5 4] 16M 16M 2M 2M 2M 4M 8M [ 7 5 11] 128M 512M 512M 128M 128M 128M 4G [ 7 8 12] 512M 4G 2G 2G 2G 128M 4G [ 7 10 7] 4M 8M 8M 2M 2M 2M 256M [ 7 12 6] 2M 8M 32M 256K 256K 256K 4G [ 8 1 1] 1M 1M 2M 8M 2M 1M 16M [ 8 1 3] 128M 256M 4M 8M 8M 16M 16M [ 8 1 6] 8M 16M 2M 2M 2M 4M 128M [ 8 5 5] 4M 4M 2M 2M 2M 4M 64M [ 8 6 8] 512K 8M 1M 256K 128K 512K 4G [ 8 8 8] 512K 1M 256K 128K 64K 32K 512M [ 8 12 8] 512K 1M 128K 128K 128K 128K 2G [ 9 2 13] 512M 2G 512M 2G 2G 128M 4G [ 9 7 2] 64M 128M 8M 8M 8M 128M 32M [ 9 9 15] 8M 32M 64M 64M 64M 32M 4G [ 9 12 9] 512K 1M 256K 128K 128K 128K 1G [ 9 16 3] 256M 512M 16M 16M 32M 128M 4G [10 1 3] 512M 2G 32M 32M 2G 128M 256M [10 1 11] 128M 512M 2G 1G 2G 128M 4G [10 2 11] 256M 1G 128M 128M 2G 128M 4G [10 4 3] 512M 2G 32M 32M 2G 128M 256M [10 4 4] 32M 64M 16M 16M 128M 128M 256M [10 8 6] 128M 128M 16M 16M 1G 128M 256M [10 10 10] 512K 1M 2M 512K 64K 128K 512M [10 12 10] 2M 4M 2M 2M 2M 1M 256M [10 12 15] 128M 256M 128M 128M 128M 128M 4G [10 15 12] 512M 256M 4G 2G 2G 128M 4G [10 16 10] 256K 512K 256K 256K 128K 128K 4G [10 16 13] 512M 512M 256M 128M 256M 128M 4G [11 1 10] 1M 2M 64M 8M 128K 64K 4G [11 1 13] 512M 1G 256M 256M 1G 128M 4G [11 2 10] 4M 16M 64M 8M 128K 64K 4G [11 2 13] 512M 2G 512M 512M 1G 128M 4G [11 3 15] 512M 4G 512M 512M 512M 128M 4G [11 5 7] 64M 512M 32M 32M 2G 128M 2G [11 7 15] 256M 512M 2G 128M 256M 128M 4G [11 12 15] 128M 256M 256M 128M 512M 128M 4G [12 4 1] 128M 1G 64M 64M 16M 16M 4G [12 8 7] 256M 256M 64M 2G 2G 128M 2G [12 9 12] 2M 4M 16M 32M 32M 16M 4G [12 12 1] 16M 32M 16M 32M 16M 16M 4G [12 12 2] 32M 256M 32M 64M 32M 32M 4G [12 12 12] 512K 1M 1M 2M 4M 4M 512M [12 13 3] 512M 1G 128M 64M 64M 128M 4G [12 14 2] 512M 512M 64M 64M 32M 32M 4G [12 15 10] 8M 16M 32M 32M 2M 128K 4G [12 16 3] 256M 1G 128M 64M 64M 64M 4G [12 16 12] 256K 512K 512K 1M 1M 512K 4G [13 1 7] 512M 1G 128M 1G 1G 128M 4G [13 1 11] 4M 16M 256K 256K 256K 128K 4G [13 2 3] 512M 2G 64M 64M 64M 64M 4G [13 2 9] 128M 256M 2G 2G 2G 128M 4G [13 2 11] 32M 64M 64M 32M 256K 128K 4G [13 6 2] 512M 8G 256M 64M 16M 32M 4G [13 6 14] 128M 512M 2G 16M 32M 8M 4G [13 9 14] 64M 128M 2G 16M 32M 8M 4G [13 10 1] 64M 128M 32M 16M 16M 16M 4G [13 10 2] 256M 1G 128M 64M 32M 64M 4G [13 11 1] 32M 64M 32M 16M 16M 16M 4G [13 14 13] 64K 1M 1M 2M 1M 1M 128M [13 16 10] 32M 32M 32M 32M 2M 2M 4G [14 5 6] 512M 1G 512M 2G 1G 128M 2G [14 6 13] 2M 32M 128M 128K 128K 64K 4G [14 9 13] 1M 4M 1G 128K 128K 64K 4G [14 10 15] 32M 32M 16M 8M 16M 8M 4G [14 14 14] 256K 256K 1M 1M 1M 1M 256M [14 15 5] 512M 1G 512M 512M 1G 128M 4G [15 3 11] 128M 64M 128M 1M 512K 256K 4G [15 6 5] 512M 1G 1G 1G 512M 128M 4G [15 7 11] 256M 128M 1G 256K 256K 256K 4G [15 9 9] 16M 64M 2M 16M 16M 16M 4G [15 10 14] 512K 1M 128K 64K 64K 64K 4G [15 12 10] 256M 128M 64M 32M 64M 128M 4G [15 12 11] 128M 64M 256K 256K 512K 512K 4G [15 14 4] 128M 1G 512M 512M 256M 128M 4G [16 1 6] 512M 1G 1G 2G 2G 128M 4G [16 6 16] 32K 512K 512K 128K 16K 16K 4G [16 8 4] 128M 2G 2G 512M 64M 32M 4G [16 10 16] 32K 128K 512K 8K 8K 8K 4G [16 12 16] 32K 64K 64K 8K 8K 16K 256M [16 16 16] 32K 32K 8K 16K 8K 16K 128MHow and where is C and Z being stored and retrieved between state iterations? What I mean is the current XORO32 method is 100% held by the D register, and can be iterated without concern for other uses of C and Z.
I need to work out how Xoro34 [7 8 12] looks in Verilog.
VHDL is bad enough ...
It's explained above but to recap I think the best way is to have a 2-bit register in hardware that stores signals I call xoro_c & xoro_z, which are the LSBs of the two 17-bit words.
The XORO34 D instruction reads the current state from D[31:0], xoro_c & xoro_z, then the xor and shift logic does it stuff, then the new state is written back to D[31:0], xoro_c & xoro_z. At the same time xoro_c is copied to C and xoro_z copied to Z.
The high 17-bit word of the new state returned is {D[31:16],C} and the low 17-bit word is {D[15:0],Z}. D[31:16] and D[15:0] are summed as now and the result incremented if C & Z (a condition which I call 'overflow'
C and Z get overwritten by XORO34 D but once summing is complete C and Z can be used for other things until the next XORO34 D. The only outstanding issue is how to set xoro_c & xoro_z to some known state during seeding.
The instruction encoding allows for two variants, one that never writes to xoro_c & xoro_z and one that does. The latter might not be strictly necessary but would make programming simpler. It could just write C to xoro_c and Z to xoro_z but that would mean setting the flags to known values.
I thought it better to write fixed values to xoro_c & xoro_z, at least one of which must be 1, with D providing the variable seed (D = 0 now permitted). 2^32 different seed values should be ample and 2^34-1 is probably overkill.
Second variant could be the only one, in which case 2-bit hardware register not required and C & Z could be stored in a second state register if necessary using software, e.g. RCZR/RCZL which look ideal for the job.
This change of mind means number of different seeds is 2^34-1.
Summary
16 bits of high-quality pseudo-random data could be achieved on the P2 using the xoroshiro34+ algorithm.
I slept on that thought last night and think it's probably not too hard to use it either. It won't be possible to skip the whole full period in a single hop though, because the skips are in powers of two so would skip just past the full period step.
EDIT: typo.
Now that we can have high-quality multiples of nice friendly 16 bits instead of horrible nasty 15 bits, would we want 31-bit results?
I'm wondering whether merging the bits from two iterations a la MERGEW would give a better 16-bit result in the top word than a single iteration.
Not only that but feeding PractRand is done in bytes anyway, so I'm repacking the output to suit that. For example, the "bit" variant does eight iterations/samples before handing a byte of data over to PractRand. The WordX samples are a tad mind bending to repack because there is continuous dangling data.
Also, you can see the comparative impact in the score tables. WordX and the ByteX variants are much of a muchness. There are exceptions of course, but those will have reasons other than a difference in data packing sizes.
That said, I still look for the scores that have WordX scores higher than ByteX scores, but the expected ratio is only 2:1 - which I feel, given PractRands sensitivity, isn't much more than the noise floor.
EDIT: This statement has an interesting twist, since PRNGs do use a fixed bit twiddle (shuffle/invert/insert) as a feature of their algorithm. What makes a modern PRNG function at all, however, is the heavy dependence on the XOR merging of multiple patterns. The bit positions that get flipped are dynamic, based on prior state.
As you can see, even with Chip's flattened logic, there is at least two layers of XORing going on with the Xoroshiro algorithm.
For example, flags from one XORO34 PRNG could be saved and those for a second PRNG restored in one instruction, then PRNG2 flags saved and PRNG3 flags restored together, etc. If less than 16 PRNGs a shift would be needed after the last one to align the flags properly ready for the next set of iterations.
The drawback with RCZR & RCZL is they are sequential. Imagine if any register could hold 16 copies of the flags, with random access for both reading and writing in a single instruction. All flag worries would disappear. Something for the P3 perhaps?
Let's call this hypothetical instruction FLAGS. Apart from D, it would need an 8-bit operand to specify separate 4-bit read and write addresses of the CZ pairs within D. FLAGS could fit into one of the empty D,S instruction slots near the bottom of the opcode map.
EDIT
Superseded. For revised details see
http://forums.parallax.com/discussion/comment/1420492/#Comment_1420492
The buffet was open about 3 years ago, most of the partygoers left last year, all drinks are drunken, the party is over.
The hosts are cleaning the house and it is simply the wrong time to open just another bottle of champagne.
Even Colombo stopped asking 'just one more question'. If Parallax want to survive they have to act.
A lot of good people went away after years of 'just one more thing' and ARM, Arduino & co took over. Its not just me @Peter J. mentioned it too.
The forum shows it clearly
No new discussions about projects somebody does with a P1, one lonely BasicStamp project. Instead we have electric cars, computer history, Cassini, Ravioli, FPGA and RISC-V discussions. Interesting discussions, but a sign that something is wrong, compared to say 1-2-3 years ago.
Meanwhile are the Dev-Tools stagnant, no new PropTool, no new Gcc, no new SipleIDE/PropellerIDE, everything and everybody is waiting for the wonders of the P2, being JUST around the corner since YEARS.
But nothing goes forward as long as there is no instruction freeze. And at least some test chips.
And then - hopefully - Parallax can update their Dev-Tools and Documentation.
And IF then - hopefully - some users are left to do something with the P2, it might be interesting again for makers to make something with it, post and discuss about it.
The Spin Group is frustrated that new products do not have Spin Example anymore and the PropTool neither uses Openspin nor supports the WiFy loader of SimpleIDE, the C Group is frustrated because even if they update Gcc, SimpleIDE will install and use the 3 year old version.
The MAC user getting frustrated because somehow you can't upload 32k-binaries anymore and BasicStamp users can't get their Boards loading at all. And nobody seems to be able to fix that.
Because - since years - nothing gets done on the dev-tools, because P2 is just around the corner.
@Ken, hit a big win with Blockly, so the educational sector keeps everything running while slowly the fan base has been moving away to more reachable fruits.
And every time it is just one more thing, and then another one. Since years.
And still I read - just one more opcode change, just a couple of more registers to save C,Z, just change the prng to 34 bit, just...
this simply has to stop or the P2 will never exist.
Mike
This Prop2 project has eaten almost a quarter of my life, now. Or, much life has happened and many other opportunities to do different things have slipped away while this project has dragged on. I feel like I'm trapped in a bubble, as the world keeps changing and heading in a direction I don't even relate to. We are right at the end of this project, though. We're ready to pay OnSemi to build this chip. That is pressing forward at full force.
Here is where I feel lost and not confident: I really like the feeling of "owning" my work and the tools needed to get my work done. Things are trending where we don't seem to own anything and the tools we use to do our work can vanish in a snap, never mind that they are bloated beyond all prior imagination. This is a tenuous situation which I find pretty demoralizing. I don't want to vest my time into things that can just vanish due to an unpaid bill, or something. I wonder if others feel this way. Younger people seem to not even think about things like this.
This is what I want to do, personally: Make a tool system that can run on-chip, that contains a file manager, editor, compiler, and debugger. The whole thing would definitely be under 32KB. It wouldn't need any internet access, authentication, email account, license, maintenance fees, etc. It would just work and you would own it. Nobody could "disappear" it. It would be there years later, still working as it did originally. No magic "updates" would alter it in some unexpected and irreversible way. You could get "married" to it, so to speak. As long as there is a need to input and output analog and digital signals on a first-principles basis, I think there's also a need for a stable and reliable platform from which to operate. This is my Luddite pipe dream. I can't help but think that people would discover how nice (and vital) it is to have a stable base on which to develop things.
While I agree with you that it is nice to own/control the whole enchilada, I really think our philosophy is disappearing quickly. I have pushed for a self-contained P1 development system, which I have done with pieces from others, there seems little interest in it.
FWIW...
Chips built with ~20nm or less only have an expected life of 10 years (min) due to trace migration.
There is of course a push for open software. While this is good for us, it's not practical for everything. Some software just needs to be done commercially. What company will be prepared to invest millions of dollars without financial returns.
That's a reasonable long term goal, but probably not good for fastest P2 product ramp. The product needs to appeal to mainstream designers.
Yes, it is nice to be 'self contained' but development these days is not done in isolation.
What you describe is quite close to the TurboPascal IDE, but that ran on DOS, and DOS had no means to view PDFs
I can't really imagine development today, without PDF readers, and some web access.
The nearest modern equivalent I can think of is Project Oberon, and I think that is much larger than 32k, and still cannot view PDF or web browse ?
Users these days expect chips to support Compilers/Assemblers, and MANY languages.
That's too much to load into 'stand alone', which will always be constrained.
Better to focus on USABILITY things like
* faster downloads
* Compilers and interpreters for P2
* Boot and run from Quad and Octal Memory
* Start Debuger design
I'm okay with development software running on PCs. Big systems do make for richness and flexibility.
Maybe to start the ball rolling on the tool chain front, you could make a command line version of Pnit and let the lurkers on this forum play with it and create a IDE or two.
Sure I am using PropTool mostly, but I do have a running Sphinx over serial just for short tests. And for fun. I envy @Peter J. and the tachyon folks, but sadly can't wrap my head around forth.
But the Sphinx Prop just works. since ~5(?) years? No updates, no hassle, running on a Protoboard with serial, so not even USB-driver needed.
This time things look even better, If @Bean is still alive when the P2 finally is there, then he can make C out of your Spin-compiler again and we can run it thru PropGcc and have a identical compiler on PC and Prop2.
Self hosting worked with the P1 and Sphinx up to say 25KB binaries, then memory of the P1 run out. Even smaller with VGA and PS2 Keyboard.
But I personally think your feeling of loss is more bound to the change in live it will bring to you to STOP working on the P2. At the time you 'delivered' the P1 you also had the point where you also did not own all the tools needed to produce it. Even now you do not really own Quartus or what it is called.
Like you I slowly start to hate all the changes done by Linux, Windows and whoever all the time on MY TOOLS so I have to rewrite all my projects again and again just because of a new hype of framework going away next year for another hype of another framework, OS or Gadget.
Sometimes I even consider to port all my work of the last 20 years back to COBOL on the backend, because the things I wrote '92 did still run on GnuCOBOL without modification as I tried last year, for fun.
I personally hope that the P2 will give me a long lasting simple personal computer, unaffected by Hype-changes and virulent malicious software. The resources are there to do it. And a nice new Multi-measurement device to check out other things. Also without mandatory updates, fees, malicious attacks from other entities.
Yes, I definitely see a lot of uses for a P2, where I failed to do so with a P1 because of running out of memory, pins or/and cogs.
My only wish would be to have the monitor back from the P2-Hot, but if typing constant enough one could program it in via serial terminal.
Enjoy!
Mike
But that is what I see with the P2.
One point with the P1 is that it has no configuration registers, Pin allocations by function and all the other garbage.
Just a block of RAM and you as a programmer, can use almost all of it for your own program.
Same still is valid for the P2. OK, some Interrupt Vectors were added.
I read some documentation how to program bare metal on some older ARM-chip. Using Keil-something, quite nice actually.
After a while I gave up reading, because they simply lost me. English is my 3. language, so I failed to follow.
But P1 and P2 have a quite simple Hub-Ram/Image layout. Up and running in 2-5 Pages of documentation, not thousands.
So one can understand what the computer does and where what is stored. That's why I plead to bring the monitor back. Even if just copied at some position after startup and over-writable by any boot loader.
But available if not overwritten, or there if no boot-media is present.
Just connect any serial terminal and you have the most minimalistic self hosted development system. You can view/edit/execute/debug any part of hub-ram.
Sure, assembler/disassembler would be nice, but not needed. Monitor alone would be sufficient.
But, yes, one can type it in serial, with the current boot loader, like the DATA statements for Atari and Commodore in the printed magazines...
Enjoy!
Mike
How long will my pc be unusable while doing the update.
Lack of control for some updates.
How much data will it use because I am on "metered internet".
What is going to break afterward the update.
For example, last month I had a little over 3GB left in my Internet quota for the month. Windows 10 wanted to update, so I foolishly let it loose while I went out. Silly me!!!! Windows update downloaded over 9GB, so I went over my limit for the month by 6GB. This cost me $60 !!!
At least to date, I haven't found anything not working. But it's early days so far.