Thinking about it, I think it will be confusing unless you specifically state for each addition if carry is to be used. Not a problem to make it first.
a := b + (carry + c) +(carry + d) - e ....
or
a := b +c c +c d - e.... <--- looks a bit confusing doesnt it???
After all, the object is to make it easier to learn pasm and also get out some rough code.
Maybe forget it for now (just like signed) and just get the basic instructions out of the way. Then see where you are up to and maybe you'll think of a great way (or someone else will) as it progresses.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I like the tick marks better. You could also create a new operator (+') for add with carry perhaps. No reason you should be limited to the same operators as other languages if you have more operations. Some languages use "**" for power, while others use "^".
For instance:
sum, carry := a + c +' d
in this case only d is added with carry.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ ·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."
I (the compiler) don't get to find out that the first "+" is supposed to be ADDX until I've burrowed into the parenthesis and parsed the "carry".
Let's say you wanted to do 64 bit addition. Longs a1 and a2 plus longs b1 and b2 results in longs r1 and r2:
r1, carry := a1 + b1
r2, carry := carry + a2 +b2
if carry
/* Ooops need more bits */
endif
OK this might restrict us to only one term per expression if you want to keep track of your carries.
Basically the "carry" on the LHS switches on "wc" for all ops in the expression and gets the resulting carry (which will be from the last op in the expression if there are many terms.)
"carry" on the RHS just gets added in as it switches on "X" for the following op.
Makes life interesting when you write:
x, carry := carry + a + b + carry + c + d
Here we have x ending up as: any existing carry + a + b + (the carry from a + b) + c + d.
and carry ending up as : The carry out of (the carry out of(a + b) + c + d).
Clear as a bell ha ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
For sure having a new operator really pins down what and where we want to do. On the other having millions of funny looking operators makes the code resemble line noise coming out of your radio modem or APL[noparse]:)[/noparse] Spin already as a huge number of operators most of which I'd like to borrow.
We don't just want carry for add and subtract. All the logical operators can generate carry as well where it indicates parity of the result. I don't think we can have tick versions of all of them. Not to mention rdlong/word/byte.
Tick marks always get lost when your eyesight is as crappy as mine. I wish Spin did not use them for comments.
Oh yeah, that's another point, we may want to avoid syntax that clashes with Spin.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I suppose adding a ' to your operators would clash with SPIN. However, I'm thinking that ADD and ADDX (for example) are two different operations and therefore using different operators would keep your syntax cleaner IMHO, and you can always choose a more appropriate character. Besides, how many operators use carry? I agree that most of them can affect the carry bit, but your multiple result idea seems to work well for that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ ·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."
This looks nice.... and its logical.
x, carry := carry + a + b + carry + c + d
Since you mentioned parity, I think you should allow "parity". You could even demand it is used correctly. I don't like the ' either. It gets lost in the noise.
I just realised - how does spin handle the carry? I don't use spin much, but don't recall any carry handling.
You could allow ; for comments if desired.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
You could just embed carry in the assignment operator.
a := b + c ' ADD
a c= b + c ' ADDX
a `= b + c ' ADDX alternative - backtick ... not spin comment tick
Problem with this of course is specifying the other effects operators: wz wr nr.
The multiple L value syntax is obviously a good generic option for the compiler and user.
The user should get used to it in the same way that wc,wz,wr,nr need special attention.
How will you deal with waitcnt? Have you given thought to mux and other special operators?
Sorry Ken when I started rambling about tick marks on all the other operators I was getting "using carry" and "setting carry" mixed up. Mind you you can rotate in and out of carry....
As far as waitcnt mux etc are concerned they farmed out to built in functions in my mind just now.
Here is the worlds first COGNAC program. It is the emulation of the dreaded DAA instruction of the 8080 CPU. No prizes for creating a shorter faster version except kudos. Also I think doing this exercise has shown up a possible bug in it!
It's about the most grungy part of the emulator so I though I'd like to see how much trouble it gave. It does show already we have some issues with conditionals "if bla bla". Conditionals that only check zero, carry, parity could just add if_c, if_z etc to the instructions in the conditional block. But then what happens when someone sets carry in the block? The execution of the rest of the block is screwed up. Or what about nested conditionals? So this is only sure to work for one instruction in the block. Also we have to allow for normal test expressions in the conditional that would use jumps to get us around.
Also makes me think we have a problem with "a, carry := b + c + d + e" What if "b+c" has already generated a carry but the final "d + e" does not and resets it again. carry becomes meaningless. Extracting carry is only sure to work for one operation.
And what about "zero := a + c + d..." We can't just set "nr" on all the ADDs as we would get only the zero of the last ADD. We do actually have to have a temporary to accumulate the result in even when we throw it away so as to get the zero correct. But for "zero := a + c" we need no temp.
The COGNAC version compares favourably to some C implementations in size and legibility.
'do_daa(alu, a_reg, flags, psw_reg) -- Params are just global COG or HUB vars we are allowed to use here
' ulong nibble -- Local variable
'begin
' alu := a_reg -- a_reg is declared HUB BYTE somewhere so use rdbyte to access it
do_daa rdbyte alu, a_reg
' flags := psw_reg -- psw_reg is declared HUB BYTE somewhere so use rdbyte to access it
rdbyte flags, psw_reg
' nibble := alu & $0F -- Isolate low nibble of accumulator
mov nibble, alu
and nibble, #$0F
' carry := nibble - 10 -- Test for greater than 9
cmp nibble, #10 wc
' zero := flags | aux_bit -- Test auxillary carry
test flags, #aux_bit wz
' if not carry or not zero -- Add 6 to accumulator if greater than 9 or AUX carry
' alu += 6
if_nz_or_nc add alu, #$06
' nibble, zero := nibble + 6 & %0010000 -- Check for AUX carry from low nibble
add nibble, #6
and nibble, #%00010000 wz
' mux_not_zero (flags, aux_bit) -- and set AUX flag if so. mux_... are built in COGNAC functions
muxnz flags, #aux_bit
' carry := alu >> 4 - 10 -- Test high nibble of accumulator for greater than 9
mov nibble, alu
shr nibble, #4
cmp nibble, #10 wc
' zero := flags & carry_bit -- Test carry flag (BUG ??? Is this the right carry we are testing?)
test flags, #carry_bit wz
' if not zero or not carry -- Add 6 to high nibble of accumulator if greater than 9 or carry
' alu += 6 << 4
if_nz_or_nc add alu, #$60
' zero := alu & $100 -- Check for 8 bit carry out
test alu, #$100 wz
' if not zero
' flags |= carry_bit -- Set carry flag if so (N.B. Do NOT clear carry if not so)
if_nz or flags, #carry_bit
' parity, zero := alu & $FF -- Get zero and parity of low 8 bits
and alu, #$FF wz, wc
' mux_zero (flags, zero_bit) -- Set 8080 zero flag from props zero
muxz flags, #zero_bit
' mux_not_carry (flags, parity_bit) -- Set 8080 parity flag from props parity(carry)
muxnc flags, #parity_bit
' zero := alu $ 128 -- Positive or negative result ?
test alu, #128 wz
' mux_not_zero (flags, sign_bit) -- Set sign_bit accordingly
muxnz flags, #sign_bit
do_daa_ret ret
end
do_daa(alu, a_reg, flags, psw_reg) -- Params are just global COG or HUB vars we are allowed to use here
ulong nibble -- Local variable
begin
alu := a_reg -- a_reg is declared HUB BYTE somewhere so use rdbyte to access it
flags := psw_reg -- psw_reg is declared HUB BYTE somewhere so use rdbyte to access it
nibble := alu & $0F -- Isolate low nibble of accumulator
carry := nibble - 10 -- Test for greater than 9
zero := flags | aux_bit -- Test auxillary carry
if not carry or not zero -- Add 6 to accumulator if greater than 9 or AUX carry
alu += 6
endif
zero := nibble + 6 & %0010000 -- Check for AUX carry from low nibble
mux_not_zero (flags, aux_bit) -- and set AUX flag if so. mux_... are built in COGNAC functions
carry := alu >> 4 - 10 -- Test high nibble of accumulator for greater than 9
zero := flags & carry_bit -- Test carry flag (BUG ??? Is this the right carry we are testing?)
if not zero or not carry -- Add 6 to high nibble of accumulator if greater than 9 or carry
alu += 6 << 4
endif
zero := alu & $100 -- Check for 8 bit carry out
if not zero
flags |= carry_bit -- Set carry flag if so (N.B. Do NOT clear carry if not so)
endif
parity, zero := alu & $FF -- Get zero and parity of low 8 bits
mux_zero (flags, zero_bit) -- Set 8080 zero flag from props zero
mux_not_carry (flags, parity_bit) -- Set 8080 parity flag from props parity(carry)
zero := alu $ 128 -- Positive or negative result ?
mux_not_zero (flags, sign_bit) -- Set sign_bit accordingly
end
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
@ ken : "Would you need tick++ WC" - I'd make all commands implicitly "WR,WC,WZ".
I think it comes down again to what one wants to achieve, a full-blown language, or an easy
to use language which aids coding for PASM for newbies. My opinion is, if you want fine-grained
control over each opcode use PASM, if you want high-level language use Spin or ImageCraft C.
This is ( if I read it right to start with ) something which sits in-between, and it seems to be being
pulled in various directions to deliver all sorts of wonderful things and I'd expect it ( from having
done such things my self in the past ) to end up delivering nothing of any real or practical use,
but it sure looked good on paper.
While it's tempting to go for bells and whistles you have to ask yourself does it actually deliver ?
And what do people actually want ? What nice does it fill ? What's its point ?
Who would be using "x, carry := carry + a + b + carry + c + d" and similar concepts ? Is it not
equally reasonable to have a more simplified form where operation is much clearer, a simple
BNF of "<vard> := <vars1> { <op> <vars2> } [noparse][[/noparse] + Carry ]" ? While it means step-by-step code (
isn't that just like PASM ) is it really that much of an inconvenience ?
That's not to say don't allow <var> to be replaced by other useful things, "long[noparse][[/noparse]<var>]", where it
makes sense and helps achieve what is required, nor to say don't provide a means to override
setting flags, why not NC or NZ at the end of the statement as per PASM ?
There's a lot of questions in there, rhetorical for me because I feel the good idea is going astray,
but they are the questions which have to be asked. I suppose this is IMO a typical case where
design by committee isn't always better than 'propriety', "here it is, like it or lump it". Everyone is
of course entirely free to disagree with me.
@ heater : You posted while I was typing. From what you have there I think we may be thinking
along the same lines. That's a good half-way house between too limited and overly complex.
heater: Along hippy's lines, I don't see myself wishing for the ability to code statements like a := b + c + carry...etc. What I struggle with in PASM is dealing with indexed variables and the like. I think if you concentrate on those aspects of PASM that are difficult and not worry about those things that are already easy in PASM, you will end up with something that is useful. In other words, perhaps a set of macros makes more sense than a full-blown language.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ ·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."
Gentlemen, trust me I'm not coding one line until this language looks "cooked" and simple enough to tackle.
Point taken about being "pulled in all directions". I know its easy to get carried away like that. However I'm just starting to think about all this and perhaps all kind of wacky things will get considered and rejected along the way. For example this whole thing about carry and zero. Maybe in the end it gets binned in favour of something more traditional and if you want juggle flags use in line PASM.
Which brings us to "normal things" that one wants to do that are weird and or troublesome in PASM.
a) As Ken points out: What to do about arrays and or "pointers". currently, no idea.
b) Passing parameters into COGs. (From Spin and from other COGNAC, after all you should be able to start a COG from COGNAC)
c) As already discussed a little passing data between COGs.
Very possibly COGNAC procedures won't have parameters or eturn values at all. Doing everything in global vars.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Two thoughts: First, I'm not clear why you want the compiler to run on the Prop itself. If the goal is just to have the prop running
native code, wouldn't it be better to have the compiler on a PC? In the PC, using C++ or whatever, you wouldn't have issues
about stacks and language limitations. You could compile any language (including Spin) and download only the machine code into the
Prop.
Second, I've had good success with something between assembler and high-order language. I found the conditional branches for the
68000 to be confusing, so I wrote a front end that would take care of them for me. I had constructs like if-then-else, for-loop, etc.
So you could have
IF predicate // predicate are things like zero, carry, etc.
<block of ASM>
ELSE
<block of ASM>
ENDIF
etc. The "compiler" looked for the keywords, and generated the appropriate tests and branches. It generated unique labels of its own,
as targets for the added jumps. It worked great, and didn't require a lot of effort on a full-up assembler. In particular, I didn't have
to worry about keeping symbol tables. The assembler took care of them.
It is not required that the compiler run on the Prop itself. There might be some confusion here as that was an idea that came up at some point as a "wouldn't it be neat?" kind of thing. If we ended up with something dead small and simple that is. Seems unlikely though. Or is it the way I defined the COGNAC acronym that gives that impression?
The issues with stacks and such is not to do with the development platform or implementation language. These are to do with the target architecture. The Propellers COGs have no hardware stack support, and no indexed addressing (for fast stack frame access) but they do have a simple and fast call/return mechanism that is just fine if you don't need recursion, which generally we do not. They also have a serious limitation in code space 496 instructions.
So the challenge is to come up with a "normal" looking language that does not need a stack, does not support recursion etc, because allowing all this eats code space and would be slow.
Then there is a desire to have the language make use of COG features like using DJNZ in loops. To add to the complication we started to consider the problems of passing parameters into COGs on start up and communication between running COGs.
I like the idea of "IF predicate" which meshes well with the Prop as COG instructions let you specify if a flag is set or not.
"Something between assembler and high-order language" is just what I'm looking for.
For sure I want to let the Prop tool or other assembler do the "heavy lifting" [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Jack Crenshaw said...
I've had good success with something between assembler and high-order language. I found the conditional branches for the 68000 to be confusing, so I wrote a front end that would take care of them for me. I had constructs like if-then-else, for-loop, etc.
That's what a good macro facility is for.·One of the things it's for, anyway.· With a versatile macro facility, all that kind of stuff is easy.· I've done all that stuff (so have many others) with the macro language of 360/370 assembler.· Any assembler worth its salt ought to have the same, especially if the assembler is running in something as powerful as a PC.
Hm. heater, I posted a fairly long answer explaining the questions about compilers, operator precedence, stacks, etc. For some reason, it's not here.
Perhaps that's just as well. This time, I'll try a _SHORT_ answer.
Operator precedence and nested parentheses are things that matter only to the compiler, not the target machine. It's true that the code generated by most modern compilers depends on a stack, but that's only because one is handy. The old IBM mainframes didn't have a stack either, nor did most of the computers of that era (only Burroughs excepted). As you suggest, without a stack you can't do recursion, but also as you suggest, nobody cares.
Without a stack, the compiled code only needs more temporaries, that's all.
For the compiler, I still much prefer a recursive-descent compiler, but even that is not a necessity.
Agreed about the temporaries instead of a stack being possible. However given the very limited space in which we have to work I was leaning toward the idea that no more variables get used than the author introduces. As much as is reasonably possible anyway.
The compiler can be recursive decent. After all there will be nested ifs, loops etc.
At which point perhaps those like Carl who suggest not bothering, just use macros, are correct.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Having attended a five hour long "interview" yesterday it looks very likely that I'm starting work for a new start up very soon[noparse]:)[/noparse] So my Propelling plans may have to take a back seat for a while.
However, I do have various bits of experimental parser, compiler code lying in around in various states of "unfinishedness". Including: A version of Jack Crenshaw's TINY language that generates Propeller LMM, very crude and inefficient but at least understands simple block structured language constructs. A more complete version of TINY with signed/unsigned BYTES, WORD, LONGS that generates Intel x86 assembler output for GCC. An almost complete PASM assembler that understands PASM syntax, Spin CON, DAT sections and the Spin syntax for defining constants and initializing data in DAT(which is quite enough work for me in itself). This assembler pretty much correctly parses everything in a .spin file except the Spin language itself (PUB/PRI).
At least one of these has moved on a bit from Jack's TINY example in that it has a tokenizer ! That's about the limit of my compiler technology.
So given all that I cant help but want to put some of these parts (actual code and/or just the concepts) together and experiment for COGNAC. I would still like a firmed up syntax first though.
Did I already put up this outline for multiple COG programming:
program -- A complete COGNAC program outline for multiple COGS
long temperature -- Some hub variables
long date
long time
cog uart (pins,baud) -- Define a UART cog
long this -- Some uart cog variables
long that
inerface tx (data)
-- define something other cogs can "call" to transmit
-- This code does not reside in this cog !
end interface
interface rx (data)
-- define something other cogs can "call" to transmit
-- This code does not reside in this cog !
end interface
-- Code for this cog goes here
end cog
cog spisd (pins, baud) -- Define a SPI SD card cog
long this -- Some uart SPI SD variables
long that
interface write_block (block_no, data)
-- define something other cogs can "call" to transmit
-- This code does not reside in this cog !
end interface
-- Code for this cog goes here
end cog
cog main () -- The first cog that is started
long baud -- Some cog variables
long pins
long u
long s
long data
baud := 9600
pins := 8
u := uart (pins, baud) -- Start a UART cog
s := spisd (pins, baud) -- Start a SPI SD cog
u.tx (data) -- Transmit something
s.write (10, data) -- Store something
pasm
-- Normal PASM assembler here
mov time, #0
...
...
end pasm
end cog
end program
All of the syntax for block delimiting, comments etc is negotiable.
I'm just exploring how we can: Write multi cog code, allow cogs to start other cogs with parameters, allow cogs to get other cogs to do something for them with parameters. All without Spin glue code and in a formalized way. Could be that these things I've written for defining COG code and interfaces are the only things that look like normal functions with parameters in COGNAC. I.E. we could not bother with a function syntnax within COGS at all!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater: Congratulations and good luck with your new endeavor!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ ·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."
I could not help but start thinking how to mix up the Propeller into said start up. They don't much want to get into hardware design/manufacture, preferring to use off the shelf kit, but I can already see they may need some small custom designed interfaces. Other micro controllers could do it, but given that it would never be for massive production runs the ease of development on the Propeller and it's flexibility could make it a winner. The ability to drive VGA screens in remote locations at the same time could clinch it.
Hmm, perhaps they would be willing to support the development of COGNAC? No, no, no, just dreaming again...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Nice code concept heater. I especially like the interface statement idea. Good luck in your new effort.
On long answers ... I remember one of my longer posts not making it to the forum once. I just shrugged my shoulders and moved on after some initial dismay and just assumed it was somehow my mistake. Now I wonder.
Comments
foo := bar + carry
or
foo := bar +c
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps (SixBladeProp)
· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz
a := b + c + d - e ...
Where, say, only c + d is Xtended.
My proposal was:
a := b + c + d' - e...
But why not just make the semantics so that
a := b + c + d .... + carry
makes all the operations Xtended. Seems more regular and if one wants selective ops to be Xtended then you have to write:
a := c + d + carry
a += b - e
Or one could use parenthesis
a := b + (c + d + carry) - e ...
Any ideas, preferences ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
a := b + c + d ... + carry
is that the parser has to look all the way to the end of the expression before it knows what to generate for the previous terms.
I don't like that.
Could we make the rule that carry has to go first?:
a := b + (carry + c + d) - e ....
After all if you are wanting to use the carry it's important enough to come first[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
a := b + (carry + c) +(carry + d) - e ....
or
a := b +c c +c d - e.... <--- looks a bit confusing doesnt it???
After all, the object is to make it easier to learn pasm and also get out some rough code.
Maybe forget it for now (just like signed) and just get the basic instructions out of the way. Then see where you are up to and maybe you'll think of a great way (or someone else will) as it progresses.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps (SixBladeProp)
· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz
For instance:
sum, carry := a + c +' d
in this case only d is added with carry.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."
- Bjarne Stroustrup
a := b + (carry + c) +(carry + d) - e ....
I (the compiler) don't get to find out that the first "+" is supposed to be ADDX until I've burrowed into the parenthesis and parsed the "carry".
Let's say you wanted to do 64 bit addition. Longs a1 and a2 plus longs b1 and b2 results in longs r1 and r2:
r1, carry := a1 + b1
r2, carry := carry + a2 +b2
if carry
/* Ooops need more bits */
endif
OK this might restrict us to only one term per expression if you want to keep track of your carries.
Basically the "carry" on the LHS switches on "wc" for all ops in the expression and gets the resulting carry (which will be from the last op in the expression if there are many terms.)
"carry" on the RHS just gets added in as it switches on "X" for the following op.
Makes life interesting when you write:
x, carry := carry + a + b + carry + c + d
Here we have x ending up as: any existing carry + a + b + (the carry from a + b) + c + d.
and carry ending up as : The carry out of (the carry out of(a + b) + c + d).
Clear as a bell ha ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
We don't just want carry for add and subtract. All the logical operators can generate carry as well where it indicates parity of the result. I don't think we can have tick versions of all of them. Not to mention rdlong/word/byte.
Tick marks always get lost when your eyesight is as crappy as mine. I wish Spin did not use them for comments.
Oh yeah, that's another point, we may want to avoid syntax that clashes with Spin.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."
- Bjarne Stroustrup
x, carry := carry + a + b + carry + c + d
Since you mentioned parity, I think you should allow "parity". You could even demand it is used correctly. I don't like the ' either. It gets lost in the noise.
I just realised - how does spin handle the carry? I don't use spin much, but don't recall any carry handling.
You could allow ; for comments if desired.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps (SixBladeProp)
· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz
a := b + c ' ADD
a c= b + c ' ADDX
a `= b + c ' ADDX alternative - backtick ... not spin comment tick
Problem with this of course is specifying the other effects operators: wz wr nr.
The multiple L value syntax is obviously a good generic option for the compiler and user.
The user should get used to it in the same way that wc,wz,wr,nr need special attention.
How will you deal with waitcnt? Have you given thought to mux and other special operators?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
As far as waitcnt mux etc are concerned they farmed out to built in functions in my mind just now.
Here is the worlds first COGNAC program. It is the emulation of the dreaded DAA instruction of the 8080 CPU. No prizes for creating a shorter faster version except kudos. Also I think doing this exercise has shown up a possible bug in it!
It's about the most grungy part of the emulator so I though I'd like to see how much trouble it gave. It does show already we have some issues with conditionals "if bla bla". Conditionals that only check zero, carry, parity could just add if_c, if_z etc to the instructions in the conditional block. But then what happens when someone sets carry in the block? The execution of the rest of the block is screwed up. Or what about nested conditionals? So this is only sure to work for one instruction in the block. Also we have to allow for normal test expressions in the conditional that would use jumps to get us around.
Also makes me think we have a problem with "a, carry := b + c + d + e" What if "b+c" has already generated a carry but the final "d + e" does not and resets it again. carry becomes meaningless. Extracting carry is only sure to work for one operation.
And what about "zero := a + c + d..." We can't just set "nr" on all the ADDs as we would get only the zero of the last ADD. We do actually have to have a temporary to accumulate the result in even when we throw it away so as to get the zero correct. But for "zero := a + c" we need no temp.
The COGNAC version compares favourably to some C implementations in size and legibility.
'do_daa(alu, a_reg, flags, psw_reg) -- Params are just global COG or HUB vars we are allowed to use here ' ulong nibble -- Local variable 'begin ' alu := a_reg -- a_reg is declared HUB BYTE somewhere so use rdbyte to access it do_daa rdbyte alu, a_reg ' flags := psw_reg -- psw_reg is declared HUB BYTE somewhere so use rdbyte to access it rdbyte flags, psw_reg ' nibble := alu & $0F -- Isolate low nibble of accumulator mov nibble, alu and nibble, #$0F ' carry := nibble - 10 -- Test for greater than 9 cmp nibble, #10 wc ' zero := flags | aux_bit -- Test auxillary carry test flags, #aux_bit wz ' if not carry or not zero -- Add 6 to accumulator if greater than 9 or AUX carry ' alu += 6 if_nz_or_nc add alu, #$06 ' nibble, zero := nibble + 6 & %0010000 -- Check for AUX carry from low nibble add nibble, #6 and nibble, #%00010000 wz ' mux_not_zero (flags, aux_bit) -- and set AUX flag if so. mux_... are built in COGNAC functions muxnz flags, #aux_bit ' carry := alu >> 4 - 10 -- Test high nibble of accumulator for greater than 9 mov nibble, alu shr nibble, #4 cmp nibble, #10 wc ' zero := flags & carry_bit -- Test carry flag (BUG ??? Is this the right carry we are testing?) test flags, #carry_bit wz ' if not zero or not carry -- Add 6 to high nibble of accumulator if greater than 9 or carry ' alu += 6 << 4 if_nz_or_nc add alu, #$60 ' zero := alu & $100 -- Check for 8 bit carry out test alu, #$100 wz ' if not zero ' flags |= carry_bit -- Set carry flag if so (N.B. Do NOT clear carry if not so) if_nz or flags, #carry_bit ' parity, zero := alu & $FF -- Get zero and parity of low 8 bits and alu, #$FF wz, wc ' mux_zero (flags, zero_bit) -- Set 8080 zero flag from props zero muxz flags, #zero_bit ' mux_not_carry (flags, parity_bit) -- Set 8080 parity flag from props parity(carry) muxnc flags, #parity_bit ' zero := alu $ 128 -- Positive or negative result ? test alu, #128 wz ' mux_not_zero (flags, sign_bit) -- Set sign_bit accordingly muxnz flags, #sign_bit do_daa_ret ret end do_daa(alu, a_reg, flags, psw_reg) -- Params are just global COG or HUB vars we are allowed to use here ulong nibble -- Local variable begin alu := a_reg -- a_reg is declared HUB BYTE somewhere so use rdbyte to access it flags := psw_reg -- psw_reg is declared HUB BYTE somewhere so use rdbyte to access it nibble := alu & $0F -- Isolate low nibble of accumulator carry := nibble - 10 -- Test for greater than 9 zero := flags | aux_bit -- Test auxillary carry if not carry or not zero -- Add 6 to accumulator if greater than 9 or AUX carry alu += 6 endif zero := nibble + 6 & %0010000 -- Check for AUX carry from low nibble mux_not_zero (flags, aux_bit) -- and set AUX flag if so. mux_... are built in COGNAC functions carry := alu >> 4 - 10 -- Test high nibble of accumulator for greater than 9 zero := flags & carry_bit -- Test carry flag (BUG ??? Is this the right carry we are testing?) if not zero or not carry -- Add 6 to high nibble of accumulator if greater than 9 or carry alu += 6 << 4 endif zero := alu & $100 -- Check for 8 bit carry out if not zero flags |= carry_bit -- Set carry flag if so (N.B. Do NOT clear carry if not so) endif parity, zero := alu & $FF -- Get zero and parity of low 8 bits mux_zero (flags, zero_bit) -- Set 8080 zero flag from props zero mux_not_carry (flags, parity_bit) -- Set 8080 parity flag from props parity(carry) zero := alu $ 128 -- Positive or negative result ? mux_not_zero (flags, sign_bit) -- Set sign_bit accordingly end▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I think it comes down again to what one wants to achieve, a full-blown language, or an easy
to use language which aids coding for PASM for newbies. My opinion is, if you want fine-grained
control over each opcode use PASM, if you want high-level language use Spin or ImageCraft C.
This is ( if I read it right to start with ) something which sits in-between, and it seems to be being
pulled in various directions to deliver all sorts of wonderful things and I'd expect it ( from having
done such things my self in the past ) to end up delivering nothing of any real or practical use,
but it sure looked good on paper.
While it's tempting to go for bells and whistles you have to ask yourself does it actually deliver ?
And what do people actually want ? What nice does it fill ? What's its point ?
Who would be using "x, carry := carry + a + b + carry + c + d" and similar concepts ? Is it not
equally reasonable to have a more simplified form where operation is much clearer, a simple
BNF of "<vard> := <vars1> { <op> <vars2> } [noparse][[/noparse] + Carry ]" ? While it means step-by-step code (
isn't that just like PASM ) is it really that much of an inconvenience ?
That's not to say don't allow <var> to be replaced by other useful things, "long[noparse][[/noparse]<var>]", where it
makes sense and helps achieve what is required, nor to say don't provide a means to override
setting flags, why not NC or NZ at the end of the statement as per PASM ?
There's a lot of questions in there, rhetorical for me because I feel the good idea is going astray,
but they are the questions which have to be asked. I suppose this is IMO a typical case where
design by committee isn't always better than 'propriety', "here it is, like it or lump it". Everyone is
of course entirely free to disagree with me.
along the same lines. That's a good half-way house between too limited and overly complex.
I would have given up by now if designing freeware.
This is a huge task. Use your best judgment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."
- Bjarne Stroustrup
Point taken about being "pulled in all directions". I know its easy to get carried away like that. However I'm just starting to think about all this and perhaps all kind of wacky things will get considered and rejected along the way. For example this whole thing about carry and zero. Maybe in the end it gets binned in favour of something more traditional and if you want juggle flags use in line PASM.
Which brings us to "normal things" that one wants to do that are weird and or troublesome in PASM.
a) As Ken points out: What to do about arrays and or "pointers". currently, no idea.
b) Passing parameters into COGs. (From Spin and from other COGNAC, after all you should be able to start a COG from COGNAC)
c) As already discussed a little passing data between COGs.
Very possibly COGNAC procedures won't have parameters or eturn values at all. Doing everything in global vars.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
native code, wouldn't it be better to have the compiler on a PC? In the PC, using C++ or whatever, you wouldn't have issues
about stacks and language limitations. You could compile any language (including Spin) and download only the machine code into the
Prop.
Second, I've had good success with something between assembler and high-order language. I found the conditional branches for the
68000 to be confusing, so I wrote a front end that would take care of them for me. I had constructs like if-then-else, for-loop, etc.
So you could have
IF predicate // predicate are things like zero, carry, etc.
<block of ASM>
ELSE
<block of ASM>
ENDIF
etc. The "compiler" looked for the keywords, and generated the appropriate tests and branches. It generated unique labels of its own,
as targets for the added jumps. It worked great, and didn't require a lot of effort on a full-up assembler. In particular, I didn't have
to worry about keeping symbol tables. The assembler took care of them.
Jack
It is not required that the compiler run on the Prop itself. There might be some confusion here as that was an idea that came up at some point as a "wouldn't it be neat?" kind of thing. If we ended up with something dead small and simple that is. Seems unlikely though. Or is it the way I defined the COGNAC acronym that gives that impression?
The issues with stacks and such is not to do with the development platform or implementation language. These are to do with the target architecture. The Propellers COGs have no hardware stack support, and no indexed addressing (for fast stack frame access) but they do have a simple and fast call/return mechanism that is just fine if you don't need recursion, which generally we do not. They also have a serious limitation in code space 496 instructions.
So the challenge is to come up with a "normal" looking language that does not need a stack, does not support recursion etc, because allowing all this eats code space and would be slow.
Then there is a desire to have the language make use of COG features like using DJNZ in loops. To add to the complication we started to consider the problems of passing parameters into COGs on start up and communication between running COGs.
I like the idea of "IF predicate" which meshes well with the Prop as COG instructions let you specify if a flag is set or not.
"Something between assembler and high-order language" is just what I'm looking for.
For sure I want to let the Prop tool or other assembler do the "heavy lifting" [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
Perhaps that's just as well. This time, I'll try a _SHORT_ answer.
Operator precedence and nested parentheses are things that matter only to the compiler, not the target machine. It's true that the code generated by most modern compilers depends on a stack, but that's only because one is handy. The old IBM mainframes didn't have a stack either, nor did most of the computers of that era (only Burroughs excepted). As you suggest, without a stack you can't do recursion, but also as you suggest, nobody cares.
Without a stack, the compiled code only needs more temporaries, that's all.
For the compiler, I still much prefer a recursive-descent compiler, but even that is not a necessity.
Jack
The compiler can be recursive decent. After all there will be nested ifs, loops etc.
At which point perhaps those like Carl who suggest not bothering, just use macros, are correct.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Having attended a five hour long "interview" yesterday it looks very likely that I'm starting work for a new start up very soon[noparse]:)[/noparse] So my Propelling plans may have to take a back seat for a while.
However, I do have various bits of experimental parser, compiler code lying in around in various states of "unfinishedness". Including: A version of Jack Crenshaw's TINY language that generates Propeller LMM, very crude and inefficient but at least understands simple block structured language constructs. A more complete version of TINY with signed/unsigned BYTES, WORD, LONGS that generates Intel x86 assembler output for GCC. An almost complete PASM assembler that understands PASM syntax, Spin CON, DAT sections and the Spin syntax for defining constants and initializing data in DAT(which is quite enough work for me in itself). This assembler pretty much correctly parses everything in a .spin file except the Spin language itself (PUB/PRI).
At least one of these has moved on a bit from Jack's TINY example in that it has a tokenizer ! That's about the limit of my compiler technology.
So given all that I cant help but want to put some of these parts (actual code and/or just the concepts) together and experiment for COGNAC. I would still like a firmed up syntax first though.
Did I already put up this outline for multiple COG programming:
program -- A complete COGNAC program outline for multiple COGS long temperature -- Some hub variables long date long time cog uart (pins,baud) -- Define a UART cog long this -- Some uart cog variables long that inerface tx (data) -- define something other cogs can "call" to transmit -- This code does not reside in this cog ! end interface interface rx (data) -- define something other cogs can "call" to transmit -- This code does not reside in this cog ! end interface -- Code for this cog goes here end cog cog spisd (pins, baud) -- Define a SPI SD card cog long this -- Some uart SPI SD variables long that interface write_block (block_no, data) -- define something other cogs can "call" to transmit -- This code does not reside in this cog ! end interface -- Code for this cog goes here end cog cog main () -- The first cog that is started long baud -- Some cog variables long pins long u long s long data baud := 9600 pins := 8 u := uart (pins, baud) -- Start a UART cog s := spisd (pins, baud) -- Start a SPI SD cog u.tx (data) -- Transmit something s.write (10, data) -- Store something pasm -- Normal PASM assembler here mov time, #0 ... ... end pasm end cog end programAll of the syntax for block delimiting, comments etc is negotiable.
I'm just exploring how we can: Write multi cog code, allow cogs to start other cogs with parameters, allow cogs to get other cogs to do something for them with parameters. All without Spin glue code and in a formalized way. Could be that these things I've written for defining COG code and interfaces are the only things that look like normal functions with parameters in COGNAC. I.E. we could not bother with a function syntnax within COGS at all!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."
- Bjarne Stroustrup
I could not help but start thinking how to mix up the Propeller into said start up. They don't much want to get into hardware design/manufacture, preferring to use off the shelf kit, but I can already see they may need some small custom designed interfaces. Other micro controllers could do it, but given that it would never be for massive production runs the ease of development on the Propeller and it's flexibility could make it a winner. The ability to drive VGA screens in remote locations at the same time could clinch it.
Hmm, perhaps they would be willing to support the development of COGNAC? No, no, no, just dreaming again...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 2/18/2009 2:10:51 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps (SixBladeProp)
· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz
On long answers ... I remember one of my longer posts not making it to the forum once. I just shrugged my shoulders and moved on after some initial dismay and just assumed it was somehow my mistake. Now I wonder.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve