Chip Gracey said...
3.3 volts. Under a 75-ohm load it goes down to 1.0 volt.
That's what I was afraid of. C'mon, Chip, that's not a 75-ohm output! See my post here.
-Phil
I see. I never thought about it that way. Well, that's simple enough to realize. I'll just have to lower the resistance and then add some resistance to VSS. Right now, I compute the new DACs resistance at 85 ohms. Not too much to change, though the internal power dissipation will rise. Thanks for speaking up about this.
heater said...
What I'm not hearing yet is "what input and output would any on board IDE be using?"
Given that the Prop is all about implementing peripheral devices in software making everything as flexible as possible then a raw un-programmed Prop has no peripherals for keyboard, mouse, screen. It has no way of knowing on which pins such things might be if they do exist or how to drive them. So if it's ROM happens to contain the necessary software for and editor and compiler etc then how would it be used?
Seems to me the IDE package in ROM would have to be absent any actual physical I/O and would never be in control at boot time. In the extreme it would simply have a standard input and standard output defined for character I/O as in the C/Unix world. stdio would then need to be physically implemented in COG software and real connected hardware by some booted application code that then calls on the IDE as required.
And what about the file system for saved source files and binaries. Same issue there.
So there it is. It's 2012, the civilized word ended as previously described, I've just looted a Prop II chip from my local distributor. My only possible computing platform is a bicycle dynamo powered ARM based Beagle board running Linux. How do do get into that chips IDE and start hacking Prop code to help rebuild civilization ?
For self-hosting IDE mode, some rules would have to exist. Maybe a few I/Os could be tied in various high/low combinations to select monitor, keyboard, mouse, comm, and storage settings. This could be the means for making a basic "computer" out of the chip. So, after getting your prop chip, you would hard-wire a few pins, connect your peripherals accordingly, and turn it on. The ROM would contain the device drivers needed to realize the configuration you selected for the IDE.
jazzed said...
INA as destination ... Cool [noparse]:)[/noparse] What is the number of cycles between HUB access per COG now?
We used to have a HUB window every 16 ticks ... this has changed if my memory serves me ... no?
You'll have six instruction slots between RD/WRxxxx instructions, with eight clocks making a round.
Thanks, Chip. This has been bothering me for awhile. I knew you'd understand! To be honest, it's been pointed out to me that the source impedance doesn't matter as long as the 75-ohm coax it's feeding is properly terminated, since the load is then purely resistive. However, any reflections from the far end due to improper termination will get re-reflected at the source end if the source impedance is wrong, possibly leading to ghosting. So it's always better to get the source impedance right. Also, a greater than 2V P-P unloaded signal can raise havoc with some sync detectors, for example, in video overlay equipment.
You are probably wondering how the current DAC can be 85 ohms, while its output under a 75 ohm load is 1.0 volt and unloaded it goes to 3.3v.
It is actually a 6-bit DAC with 32 levels being used for black..white, with black beginning at $11 and white going to $30. The max output of $3F is never used, though some modulations will definitely exceed $30.
So, I need to load that thing a little more internally and then decrease the resistance of the 64 resistors that sum together to make the output. Actually, it has two extra LSBs that can be used for sine output, but that's another story.
I really appreciate you pointing this impedance·issue out. I will·modify the R/G/B DACs, as well, to give them true 75-ohm impedance. This would have been·a sorry oversight, otherwise.
Did you try any more experiments with integrating the dither into the _frqa value, and then writing the _frqa to FRQA? How about the original approach, but instead of signed LFSR noise, use a -8 to +8 ramp positioned down where the offending bits are? To get through 17 steps at 2.5MHz would place the ramp at 147KHz.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 11/26/2009 8:16:17 AM GMT
I have many questions.
BUT ends ti give You only 2.
1. In Propeller I ... to start and PASM compiled code I musy have litle SPIN stub to load it in COG for Runing.
and if I stop COG I can't simply restart it without RELOADIG its code (In my aplication that HUB area are already after START used by other things - with Reloading it will be only Smile).
Question. Will it be posible to start All COG's without that SPIN stub as pure PASM code and will it be posible to STOP/RESTART COG without reloading?
2. In propeller I if I send/receive serialised data I must every bit separately to have correct MSB-LSB positions in BYTE/WORD/LONG.
Question. It is posible to implement INSTRUCTION that reorder MSB-LSB in that BYTE/WORD/LONG in one instruction to simplicity serial communication.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Chip Gracey said...
You are probably wondering how the current DAC can be 85 ohms, while its output under a 75 ohm load is 1.0 volt and unloaded it goes to 3.3v.
Well, yes, I did wonder about that! ('Still trying to grok your explanation. 'Seems to violate Ohm's law somehow...)
I really like the 32-level intensity output, BTW. For composite video, what kind of options will we have this time 'round for hue and saturation? (Please forgive me if I misssed it in an earlier post.)
I have many questions.
BUT ends ti give You only 2.
1. In Propeller I ... to start and PASM compiled code I musy have litle SPIN stub to load it in COG for Runing.
and if I stop COG I can't simply restart it without RELOADIG its code (In my aplication that HUB area are already after START used by other things - with Reloading it will be only Smile).
Question. Will it be posible to start All COG's without that SPIN stub as pure PASM code and will it be posible to STOP/RESTART COG without reloading?
Yes, the booter in the next Propeller will launch assembly code·instead of Spin code. Any cog that is (re)started must load up, entirely.
2. In propeller I if I send/receive serialised data I must every bit separately to have correct MSB-LSB positions in BYTE/WORD/LONG.
Question. It is posible to implement INSTRUCTION that reorder MSB-LSB in that BYTE/WORD/LONG in one instruction to simplicity serial communication.
It is possible, but I'm not convinced that it's worth making an instruction for. Could you give me an example of what you'd like?
Chip Gracey said...
You are probably wondering how the current DAC can be 85 ohms, while its output under a 75 ohm load is 1.0 volt and unloaded it goes to 3.3v.
Well, yes, I did wonder about that! ('Still trying to grok your explanation. 'Seems to violate Ohm's law somehow...)
It outputs 1.0v under 75-ohm load with the DAC set to $30 ($3F being max, which would output something like 1.4v under 75 ohms).
I really like the 32-level intensity output, BTW. For composite video, what kind of options will we have this time 'round for hue and saturation? (Please forgive me if I misssed it in an earlier post.)
You said "Any cog that is (re)started must load up, entirely."
That was BAD for my programing structures and posiblity to reuse HUB memory
Many times I ned simply STOP COG and then restart it without REloading (I know its code is ok and runing only stoped)
What about my second question?
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
You said "Any cog that is (re)started must load up, entirely."
That was BAD for my programing structures and posiblity to reuse HUB memory
Okay. This is a different way of using the chip. I'll have to give this some thought, because some initialization is performed during the (re)start. Perhaps you just need a clock-inhibit control through the hub mechanism to shut down any cog.
Many times I ned simply STOP COG and then restart it without REloading (I know its code is ok and runing only stoped)
What about my second question?
I need you to give me an example of what you'd like, because I'm not sure that I understand. Do you just want the bytes' bits reversed, with the bytes remaining in their byte positions? I need to be convinced that there is a compelling reason to make an instruction to do this.
Thanks for answer.
I we not thinking about CLOCK-inhibit .... My direct thinking in that case is simple restart of Program counter to 000000
IF posible FROM any other COG enter one INSTRUCTION that tels
RESTART COGx .... that will simply restart that COG's PC counter to 000000
On second question I will post tomorow some pictures that will give YOU all answers on this
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
If You put COG to sleep ... You can't simple skip sleep and have COG runing again .... IF You will not waste PIN's to semi interupts
Regards
Ps. And that not give YOU full control of COG rfom any other.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Chip Gracey said...
Yes, the booter in the next Propeller will launch assembly code instead of Spin code.
It does that now, sort of, in that it launches the (machine code) Spin interpreter from ROM. Does this mean, though, that beginning Spin programmers will now have to include an assembly language stub to lauch the interpreter? Or will pure Spin programs include that stub automatically?
To that neds one flag in BOOT UPP stub that simple tell Propeller if it is SPIN else PURE PASM code to BOOT
Regards
Christoffer
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Chip Gracey said...
It outputs 1.0v under 75-ohm load with the DAC set to $30 ($3F being max, which would output something like 1.4v under 75 ohms).
I get closer to 102 ohms, then: 1.4V / 75 ohms = 18.7 mA, and (3.3Vunloaded - 1.4Vloaded) / .0187 = 101.6 ohms. I'm sure I'm missing something...
-P.
I don't have access to my chip tools today, but I recall 21.85um * 1.25um poly resistors with 311 ohms/square sheet resistance. There are 64 of these in parallel, each driven by a tristate driver. The resistance of each is 21.85um/1.25um * 311 ohms = 5,436 ohms. Divide that by 64 to get the summed resistance and it comes out to 84.94 ohms. With all driven high, then going through an external·75-ohm resistor to ground, you'd have 3.3V ---> 85 ohms ---> 75 ohms ---> GND. That's 160 ohms dropping 3.3V. Current is 3.3/160, or 20.625mA. The 75-ohm resistor would drop .020625*75, or 1.55V. Does that all make sense?
In my programing PAR is not usable in Propeller I because it not have posiblity to reload from COG.
I use Addresing initiated as Variables in LONG's in COG
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Chip Gracey said...
Yes, the booter in the next Propeller will launch assembly code instead of Spin code.
It does that now, sort of, in that it launches the (machine code) Spin interpreter from ROM. Does this mean, though, that beginning Spin programmers will now have to include an assembly language stub to lauch the interpreter? Or will pure Spin programs include that stub automatically?
-Phil
It just means an assembly program will be launched, instead of the Spin interpreter, from somewhere near the start of RAM. In less bytes than a stub would take, that program could launch the Spin interpreter, or do something else. Once Spin is running, everything would be like it is in the current Prop. This is just a way to let people go straight to assembly if they wish, without having to play any Spin games.
Phil Pilgrim (PhiPi) said...
So, if it's pure assembly code, what does PAR get loaded with?
-Phil
Perhaps 0. After all, the program being loaded knows that it is the start of user code. It wouldn't need any pointers, as it could already be hard-coded with them.
Perhaps that initial PAR value could indicate which boot media was actually used for the current boot. Could be useful for a program to know where it is sometimes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
You said "Any cog that is (re)started must load up, entirely."
That was BAD for my programing structures and posiblity to reuse HUB memory
Okay. This is a different way of using the chip. I'll have to give this some thought, because some initialization is performed during the (re)start. Perhaps you just need a clock-inhibit control through the hub mechanism to shut down any cog.
Many times I ned simply STOP COG and then restart it without REloading (I know its code is ok and runing only stoped)
What about my second question?
I need you to give me an example of what you'd like, because I'm not sure that I understand. Do you just want the bytes' bits reversed, with the bytes remaining in their byte positions? I need to be convinced that there is a compelling reason to make an instruction to do this.
Regards
Christoffer J
Sapieha said...
Hi Chip Gracey (Parallax)
Thanks for answer.
I we not thinking about CLOCK-inhibit .... My direct thinking in that case is simple restart of Program counter to 000000
IF posible FROM any other COG enter one INSTRUCTION that tels
RESTART COGx .... that will simply restart that COG's PC counter to 000000
On second question I will post tomorow some pictures that will give YOU all answers on this
Regards
Christoffer J
Regarding the cog "sleep/hibernation" feature I thing that Chip solution is the way to go but the clock inhibit should be set in cog. Trough the hub the other cogs should have the possibility to read this state and reset it. This is the same as setting PC to zero if you jump eg to reg1 where this instruction is. the reg 0 can unconditionally jump to reg2 for the first time code execution. Resetting PC to 0 from other cogs without knowing at what stage the code in the resetted cog is can be dangerous since the IOs can remain in unknown state.
Regarding the the second question I think Sapieha means to swap the bytes. As I usually do a lot of industrial programming on PLC (Siemens, Telemecanique ...) when you have to make them comunicating together and with PCs you have always to deal with big/little endian notations. Two instructions to swap the bytes on word and long basis will be helpful to safe some shifting, masking ...
@Chip, what about my question here http://forums.parallax.com/showthread.php?p=858929. I am specially interested in movs/movd instructions. You have put together a magnificent assembler and more an as more I familiarize with it and its sefl-modifyng possibilities the more I love it. Now (hope you have understood the way I'd like these two instructions to work with and without the wc flag set - source selector switch, Carry flag not modified) when I execute a line (where the destination was modified by previous instruction) and next execution is based upon the result of this line you can save a lot of lines with this. Here is an example:
Phil Pilgrim (PhiPi) said...
So, if it's pure assembly code, what does PAR get loaded with?
YOU said
-Phil
Perhaps 0. After all, the program being loaded knows that it is the start of user code. It wouldn't need any pointers, as it could already be hard-coded with them.
IN my opinion ..... PAR can be SET to ADDRES after START parameters area in HUB .... If I'm are correct it is 10H (same addres as Start of SPIN Parameter block) FOR compatiblity with Spin and Old Propeller I programs
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Since you are implementing 3 x 32 bit ports and an 8 bit port for "D", could D be fully implemented as 32 bits, but only 8 with external drivers? This way we would have 24 bits on port D for cog to cog communications. Another use could be the counters where currently we have to output on one pin as a clock which gets used internally, but wastes a pin.
Will the remaining longs above the registers be available as cog ram ? (Like we use the shaddow ram in the lower ones now - yes I realise we will not be able to use the shaddow ram on the new registers as they are now both r & w). If so, might it be prudent to move the registers to the top section of cog ($1FA-$1FF if 6 registers). This way we get some extra cog ram (10 longs).
Are the hub r & w's going to have quad-word transfers as well (per access)? As previously mentioned.
Someone asked (dMajo?) about always writing the result to a special register whether the nr bit was active or not. That could·be a decoding issue as two writes may have to be done simultaneously. However, an alternative could be, if the nr is specified, then the result is written to a special register which could just be a cog address (either $1F7 as the first available after the special registers, or if you move the 6 registers to the top, then $1F9). While you would call this a register "NR" in fact it would just be cog memory location which overrides the D address in the nr instruction.
You have indicated there will be no "PAR" register. How will we pass a pointer to a set of hub data? This could be handled by a compiler extension which places a hub address within the cog compiled code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
@Cluso99: sorry maybe is my fault. I was told/teached that cpu that work like prop (data and instruction in the same space aligned in this way) is register based cpu/uC so I intend that the cog has 512 32bit registers (memory locations) where the last 16 are not general pourpose but have special functions. In that post when I asked if every instruction can, regardless of the nr/wr flag, overwrite reg0 it was intended memory location 0 (your first line of pasm code)
The same apply for the movs/movd request as you can see from the above example where the wc flag on the movs line is used ONLY as switch (selector) of which packet of source bits to transfer to destination.
BTW: I came to this when I was looking to port my regulator from SiemensS7 to prop. It was developed in mathlab and then the algorithms was semplified in order to implement it with the basic plc instruction set.·It was called·"Bumpless regulator with anti-windup and feedforward" because it have feedforward capabilities, it not wind-up if the procces variable is loosen (breakdown of the sensor) and is not bumping when you are switching it from auto mode to manual and back to auto again. The implementation basically consists of 3 fifos that are multiplied by 3 arrays (all of them 11 elements: because it was meant to go to 10th order, but I have never used it above the 6th) ans summed toghether. It is based on the optimal regulator·theory with embedded kalman filtering.
Now PropII will have the multiply instruction and when I was looking how to sum the multiply results without changing the factors nor the multipliers I had this idea (Reg0)·in order to short the code and gain in speed.
@dMajo: In fact, on the prop I each cog has 512 long ram locations as well as 16 registers which are overlaid onver the top 16 longs. Some of these ram locations can be accessed - we call this shaddow ram. I have a debugger that totally lives in the first 4 ($1F0-$1F3) shaddow ram locations. So you see, there are ram and registers.
I do not like the fact of overwriting ram location $0. This would break some lookup tables we place there ( $0 contains a jump and the next instruction executed replaces $0 with the 1st lookup table value). However, using the nr bit to force the destination to be a specific register/location would be useful. One has to consider if the long used for this would be better served for an extra cog instruction.
As for the movs/movd, simplistically, what you are after is 2 extra instructions movsd dest, src and movdd dest, src.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99: I have said $0 because this is the firs insrtruction and most of the times is some setup of something (eg counter, video ...) that need to be executed only once and was on one extreme. I can say $495 that is on the other extreme before the first register but I had the feeling that this would be more a wasted memory location than $0.
Supponing you have MUL instruction working the same way as ADD (so dest=dest*source) and make this x= a*b+c*d+e*f+g*h+i*j+k*l in both ways
This is my way
==============
Mem0: nop
mul a, b nr
add sum, mem0
mul c, d nr
add sum, mem0
mul e, f nr
add sum, mem0
mul g, h nr
add sum, mem0
mul i, j nr
add sum, mem0
mul k, l nr
add sum, mem0
but we can have a special register to choose the "common result" address (which memory location to overwrite)
As per movs/movd from the manual I have seen that these instruction don't set carry nor zero flags so I have thought why not use wc (or wz is the same) as the area selector of the source memory location? Now how you can copy bits 9..17 of one memory location [noparse][[/noparse]source]·to bits 0-8 (or bits 9..17) of the other memory location [noparse][[/noparse]destination] with a single instruction? In order to not waste a new instruction opcode I have choosen to add a input (source) mux to the existing one. This speed up (and save many temp variables and code lines) in a lot of algorithms (search, sort, multiple compare) using self-modifying code
BTW: @Chip, how is the instruction fetching of the new PropII made? It will be still necessary to interpose a line between the modifier and the modified code lines?
It is not good idea to use $0 register to that.
In most of my algoritms I must aloways have JMP RUNcode and my idea to Chip on simple RESET COG without reload needs that JMP to function correctly.
Regards
ChJ
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
-Phil
You are probably wondering how the current DAC can be 85 ohms, while its output under a 75 ohm load is 1.0 volt and unloaded it goes to 3.3v.
It is actually a 6-bit DAC with 32 levels being used for black..white, with black beginning at $11 and white going to $30. The max output of $3F is never used, though some modulations will definitely exceed $30.
So, I need to load that thing a little more internally and then decrease the resistance of the 64 resistors that sum together to make the output. Actually, it has two extra LSBs that can be used for sine output, but that's another story.
I really appreciate you pointing this impedance·issue out. I will·modify the R/G/B DACs, as well, to give them true 75-ohm impedance. This would have been·a sorry oversight, otherwise.
Did you try any more experiments with integrating the dither into the _frqa value, and then writing the _frqa to FRQA? How about the original approach, but instead of signed LFSR noise, use a -8 to +8 ramp positioned down where the offending bits are? To get through 17 steps at 2.5MHz would place the ramp at 147KHz.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 11/26/2009 8:16:17 AM GMT
I have many questions.
BUT ends ti give You only 2.
1. In Propeller I ... to start and PASM compiled code I musy have litle SPIN stub to load it in COG for Runing.
and if I stop COG I can't simply restart it without RELOADIG its code (In my aplication that HUB area are already after START used by other things - with Reloading it will be only Smile).
Question. Will it be posible to start All COG's without that SPIN stub as pure PASM code and will it be posible to STOP/RESTART COG without reloading?
2. In propeller I if I send/receive serialised data I must every bit separately to have correct MSB-LSB positions in BYTE/WORD/LONG.
Question. It is posible to implement INSTRUCTION that reorder MSB-LSB in that BYTE/WORD/LONG in one instruction to simplicity serial communication.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
I really like the 32-level intensity output, BTW. For composite video, what kind of options will we have this time 'round for hue and saturation? (Please forgive me if I misssed it in an earlier post.)
-Phil
Chip Gracey
Parallax, Inc.
Chip Gracey
Parallax, Inc.
You said "Any cog that is (re)started must load up, entirely."
That was BAD for my programing structures and posiblity to reuse HUB memory
Many times I ned simply STOP COG and then restart it without REloading (I know its code is ok and runing only stoped)
What about my second question?
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Chip Gracey
Parallax, Inc.
Couldn't you just put the cog to sleep with one of the WAIT instructions?
-P.
Thanks for answer.
I we not thinking about CLOCK-inhibit .... My direct thinking in that case is simple restart of Program counter to 000000
IF posible FROM any other COG enter one INSTRUCTION that tels
RESTART COGx .... that will simply restart that COG's PC counter to 000000
On second question I will post tomorow some pictures that will give YOU all answers on this
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
If You put COG to sleep ... You can't simple skip sleep and have COG runing again .... IF You will not waste PIN's to semi interupts
Regards
Ps. And that not give YOU full control of COG rfom any other.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
-Phil
To that neds one flag in BOOT UPP stub that simple tell Propeller if it is SPIN else PURE PASM code to BOOT
Regards
Christoffer
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
In my programing PAR is not usable in Propeller I because it not have posiblity to reload from COG.
I use Addresing initiated as Variables in LONG's in COG
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Regarding the the second question I think Sapieha means to swap the bytes. As I usually do a lot of industrial programming on PLC (Siemens, Telemecanique ...) when you have to make them comunicating together and with PCs you have always to deal with big/little endian notations. Two instructions to swap the bytes on word and long basis will be helpful to safe some shifting, masking ...
@Chip, what about my question here http://forums.parallax.com/showthread.php?p=858929. I am specially interested in movs/movd instructions. You have put together a magnificent assembler and more an as more I familiarize with it and its sefl-modifyng possibilities the more I love it. Now (hope you have understood the way I'd like these two instructions to work with and without the wc flag set - source selector switch, Carry flag not modified) when I execute a line (where the destination was modified by previous instruction) and next execution is based upon the result of this line you can save a lot of lines with this. Here is an example:
Median Filter (3) With new instruction ============================================== ======================================== CMP MEM2, INPUT wc CMP MEM2, INPUT wc if_c MOVS Med31, @INPUT if_c MOVS Med31, @INPUT if_nc MOVS Med31, @MEM2 if_nc MOVS Med31, @MEM2 MOVD Med32, Med31 MOVD Med32, Med31 if_c MOVS Med33, @MEM2 if_c MOVS Med33, @MEM2 if_nc MOVS Med33, @INPUT if_nc MOVS Med33, @INPUT Med31 CMP MEM3, @0 wc Med31 CMP MEM3, @0 wc if_c MOVD Med32, @MEM3 if_c MOVD Med32, @MEM3 NOP NOP Med32 CMP @0, @0 wc Med32 CMP @0, @0 wc [color=red] MOV Temp, Med32 SHR Temp, #9 if_c MOVS Med33, Temp if_c MOVS Med33, Med32 wc[/color] ;this WC is source mux ctrl bit; the instructon doesn't modify the carry flag NOP NOP Med33 MOV OUTPUT, @0 Med33 MOV OUTPUT, @0 MOV MEM3, MEM2 MOV MEM3, MEM2 MOV MEM2, INPUT MOV MEM2, INPUT▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates);·· Vaati's custom search
Post Edited (dMajo) : 11/26/2009 3:39:52 PM GMT
Phil Pilgrim (PhiPi) said...
So, if it's pure assembly code, what does PAR get loaded with?
YOU said
-Phil
Perhaps 0. After all, the program being loaded knows that it is the start of user code. It wouldn't need any pointers, as it could already be hard-coded with them.
IN my opinion ..... PAR can be SET to ADDRES after START parameters area in HUB .... If I'm are correct it is 10H (same addres as Start of SPIN Parameter block) FOR compatiblity with Spin and Old Propeller I programs
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Since you are implementing 3 x 32 bit ports and an 8 bit port for "D", could D be fully implemented as 32 bits, but only 8 with external drivers? This way we would have 24 bits on port D for cog to cog communications. Another use could be the counters where currently we have to output on one pin as a clock which gets used internally, but wastes a pin.
Will the remaining longs above the registers be available as cog ram ? (Like we use the shaddow ram in the lower ones now - yes I realise we will not be able to use the shaddow ram on the new registers as they are now both r & w). If so, might it be prudent to move the registers to the top section of cog ($1FA-$1FF if 6 registers). This way we get some extra cog ram (10 longs).
Are the hub r & w's going to have quad-word transfers as well (per access)? As previously mentioned.
Someone asked (dMajo?) about always writing the result to a special register whether the nr bit was active or not. That could·be a decoding issue as two writes may have to be done simultaneously. However, an alternative could be, if the nr is specified, then the result is written to a special register which could just be a cog address (either $1F7 as the first available after the special registers, or if you move the 6 registers to the top, then $1F9). While you would call this a register "NR" in fact it would just be cog memory location which overrides the D address in the nr instruction.
You have indicated there will be no "PAR" register. How will we pass a pointer to a set of hub data? This could be handled by a compiler extension which places a hub address within the cog compiled code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
The same apply for the movs/movd request as you can see from the above example where the wc flag on the movs line is used ONLY as switch (selector) of which packet of source bits to transfer to destination.
BTW: I came to this when I was looking to port my regulator from SiemensS7 to prop. It was developed in mathlab and then the algorithms was semplified in order to implement it with the basic plc instruction set.·It was called·"Bumpless regulator with anti-windup and feedforward" because it have feedforward capabilities, it not wind-up if the procces variable is loosen (breakdown of the sensor) and is not bumping when you are switching it from auto mode to manual and back to auto again. The implementation basically consists of 3 fifos that are multiplied by 3 arrays (all of them 11 elements: because it was meant to go to 10th order, but I have never used it above the 6th) ans summed toghether. It is based on the optimal regulator·theory with embedded kalman filtering.
Now PropII will have the multiply instruction and when I was looking how to sum the multiply results without changing the factors nor the multipliers I had this idea (Reg0)·in order to short the code and gain in speed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates);·· Vaati's custom search
Post Edited (dMajo) : 11/26/2009 2:19:10 PM GMT
I do not like the fact of overwriting ram location $0. This would break some lookup tables we place there ( $0 contains a jump and the next instruction executed replaces $0 with the 1st lookup table value). However, using the nr bit to force the destination to be a specific register/location would be useful. One has to consider if the long used for this would be better served for an extra cog instruction.
As for the movs/movd, simplistically, what you are after is 2 extra instructions movsd dest, src and movdd dest, src.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Supponing you have MUL instruction working the same way as ADD (so dest=dest*source) and make this x= a*b+c*d+e*f+g*h+i*j+k*l in both ways
This is my way ============== Mem0: nop mul a, b nr add sum, mem0 mul c, d nr add sum, mem0 mul e, f nr add sum, mem0 mul g, h nr add sum, mem0 mul i, j nr add sum, mem0 mul k, l nr add sum, mem0but we can have a special register to choose the "common result" address (which memory location to overwrite)
As per movs/movd from the manual I have seen that these instruction don't set carry nor zero flags so I have thought why not use wc (or wz is the same) as the area selector of the source memory location? Now how you can copy bits 9..17 of one memory location [noparse][[/noparse]source]·to bits 0-8 (or bits 9..17) of the other memory location [noparse][[/noparse]destination] with a single instruction? In order to not waste a new instruction opcode I have choosen to add a input (source) mux to the existing one. This speed up (and save many temp variables and code lines) in a lot of algorithms (search, sort, multiple compare) using self-modifying code
BTW: @Chip, how is the instruction fetching of the new PropII made? It will be still necessary to interpose a line between the modifier and the modified code lines?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates);·· Vaati's custom search
It is not good idea to use $0 register to that.
In most of my algoritms I must aloways have JMP RUNcode and my idea to Chip on simple RESET COG without reload needs that JMP to function correctly.
Regards
ChJ
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha