Only thing I see is that SETSE1/2/3/4 could move into one of the spare slots above which could allow the POLLINT..NIXINT3 to use SSSSSSSSS=000100000 which then affects the xxx/SETINT1/2/3and drops another line of spares at SSSSSSSSS=0001001ff.
Probably not worth changing ???
The spare slots within CLKSET..QEXP are not worth using because that whole range is decoded as %00000xxxx, so that the 4 LSB's form hub commands. The other slot values get filled in with COGINIT..QVECTOR codes.
That makes sense
It would be neat to not use the D field for POLLINT..NIXINT3 and just use the S field, since there's plenty of space available. Wish I had done that. Would have kept things simpler and cleaner.
Yes. Using S certainly contributed a lot of instruction expansion space when S wasn't required.
The instruction space is nice and tidy now. Did you see my latest post above where it breaks out the instruction space? eg see ROLBYTE
Did AUGS & AUGD need to be 2 clocks or was it just easier to keep it standard?
Is RDLUT 3 clocks for both cog-exec and lut-exec?
Is WRLUT 2 clocks for both cog-exec and lut-exec?
Every instruction must take at least two clocks, even AUGx.
RDLUT/WRLUT occur on phase one. Instruction read occurs on phase two. So, RDLUT always takes three clocks, from any execution mode.
1. Sometime ago, the subject of replacing ifnot with unless came up. Perl uses unless, and it's very natural, in that it's the way we would say things in conversation. However, things get complicated when you add an else clause to the mix. In that scenario, I think that ifnot is less confusing.
2. In Spin, the limits of the repeat <var> from <expr> to <expr> are recomputed every time through the loop. It would be nice if there were a shorthand alternative that allowed the <expr>s to be computed just once at the beginning. The side effects of recomputing the limits every time through can not only be confusing, but in many cases unwanted.
3. I would go along with single-line if/else statements, in both prescript and postscript forms, but not as a substitute for the ternary operator.
Heater,
Sorry, man but I strongly disagree with you on the Ternary operator. It's invaluable and clean. I am baffled why you hate them.
I also feel that it absolutely needs to be the normal ? : set and not some weird keyword variant. The random operator can just become a keyword thing. I thousands of spin files I have run through openspin for testing, I've run into once or twice at most.
Ken,
pnut uses delphi and pnut needed some updates for this go around.
Ken,
pnut uses delphi and pnut needed some updates for this go around.
PropBASIC uses FreePascal/Lazarus, which is open source, and rather more portable than Delphi.
(eg there is a FreePascal on RaspPi)
which can be Delphi compatible in many cases, especially in command line pgms.
How does PNUT compile in FreePascal ?
I think a single line if-else is worthwhile, but I'm less convinced a special new syntax is needed.
It is needed. The ternary operator can be used as part of an expression, thus:
c := (a < 5 ? 5 : a) * 10
That's its primary utility, not just as a single-line if/else.
-Phil
That's right. It's awfully handy.
Agreed. I don't care about the form. If we want just the "?"", fine. SPIN has lots of operators, and that's a strength IMHO. Adding one for this won't change things much.
But, I'm in favor of adding this. It's just too common of a program flow to omit.
To allow the common syntax of the Ternary the random operator could just change to ?? instead of ? and all is fine.
with :=,+=,-=, <=,>=,#<,#> and some others it should be understandable for a user and as well for a parser.
As for build in commands for things like i2c, serin/out, spi and all those nifty protocols, I am strongly opposed to add this to the compiler/interpreter.
Like the P1, the P2 will use soft devices, it is one of the main advantages. The language should just be that, the language. Everything else can be loaded as needed, like in spin1.
Just make objects out of it, most of them will not even need a cog, just inline pasm in a object.
Thankfully @Roy stated that building the runtime depending on the actual program is possible, I think this is a really needed feature, sort of removal of unused methods from a object, removal of unused byte codes and implementation from the used interpreter.
This will shrink down the size of a program+spin2 and that is basically a very good thing.
Defining the language (and so the interpreter) as small and lean as possible and not filling up a complete cog, could enable us to not just having some stack in the cog but maybe user defined data.
some peek and poke for the interpreter-cog your program is actual running on would be nice.
Heater,
I find the one line with ternary version easier to read.
I agree about random being a function/method (built in?) instead of a keyword. That's more what I meant anyway. I think Spin keywords should be paired down to the real language stuff, and other stuff should be a kind of standard library or instrinsics type stuff.
To allow the common syntax of the Ternary the random operator could just change to ?? instead of ? and all is fine.
with :=,+=,-=, <=,>=,#<,#> and some others it should be understandable for a user and as well for a parser.
As for build in commands for things like i2c, serin/out, spi and all those nifty protocols, I am strongly opposed to add this to the compiler/interpreter.
Like the P1, the P2 will use soft devices, it is one of the main advantages. The language should just be that, the language. Everything else can be loaded as needed, like in spin1.
Just make objects out of it, most of them will not even need a cog, just inline pasm in a object.
Thankfully @Roy stated that building the runtime depending on the actual program is possible, I think this is a really needed feature, sort of removal of unused methods from a object, removal of unused byte codes and implementation from the used interpreter.
This will shrink down the size of a program+spin2 and that is basically a very good thing.
Defining the language (and so the interpreter) as small and lean as possible and not filling up a complete cog, could enable us to not just having some stack in the cog but maybe user defined data.
some peek and poke for the interpreter-cog your program is actual running on would be nice.
Enjoy!
Mike
Mike, will you be writing Cobol programs in Spin2?
I look forward to programming with a ternary operator. It makes selection really easy.
I agree about random being a function/method (built in?) instead of a keyword.
It would either have to be call-by-reference, which violates consistency with the rest of Spin, or the programmer would have to prepend an @ to the argument. And you'd have to have two functions: one for the prefix and one for the postfix version of ?.
Maybe replace with ? with ?> and <? , both as prefix operators.
Why oh why do we need the horrible confusion of ternary expressions?
In fastspin's case I needed a ternary operator internally to implement some ranged bit expressions (things like outa[x..y] := z needed different handling depending on whether x < y). Since I had to implement it anyway it was trivial to expose it to the user. It's actually pretty common -- I think even Algol had it didn't it? (I'm sure Algol68 did, at least.)
I'm not opposed to ternary operators but can't help wondering how many ways we need to do the same thing, and how terse do we want to make them.
The advantage is that the ternary operator can be used in an expression. A regular if statement can't.
Ah, never thought of that. Moves me from "not opposed" to in favor.
Mike, will you be writing Cobol programs in Spin2?
I look forward to programming with a ternary operator. It makes selection really easy.
Yes, I am looking forward to compile COBOL to run on a P2. My favorite COBOL at this time is GnuCobol, a 'transpiler' producing C source out of COBOL.
Sadly GnuCobol - by now - needs dynamic linking and PropGCC does just support static linking on the P1. My hope is that PropGCC for P2 will support dynamic linking, but I also try to convince the GnuCOBOL guys to support 100% static linked programs, by now they use both, but still need some stuff linked dynamic.
Most of my P1 projects are running out of code space and for that reason I advocate for a modular design of Spin2 compiler and interpreter, so just needed things end up in the binary.
Should Spin2 support separate compilation, libraries, and linking? I know people argued that was not needed for P1 because of the limited 32k address space but we now have a 512k address space and compiling code monolithically might take longer than with the P1 Spin.
Should Spin2 support separate compilation, libraries, and linking?
The only change I would recommend is a way, in the OBJ section, to specify directories for objects. But separating out the compile, linking, and loading phases? Ugh, no. Single compile and compile-and-load buttons (F9, F10, F11) keep things simple.
Should Spin2 support separate compilation, libraries, and linking? I know people argued that was not needed for P1 because of the limited 32k address space but we now have a 512k address space and compiling code monolithically might take longer than with the P1 Spin.
Ugh, no. Single compile and compile-and-load buttons (F9, F10, F11) keep things simple.
Also a valid point, but they are not mutually exclusive.
Certainly simple single-build buttons are easy to use, but separate linking allows a mix of languages, and as David says, on 512k+ address space, this could give significant speed gains. Easy to do both.
large FONT tables, for example, can be late-linked, no need to re-compile those every time..
Some users want to run P2 tools on quite feeble platforms, so design-for-speed matters more than on a big PC box.
I agree with Phil on the default path. Press the button and go. People can write big programs that will take some time, but that comes later. When they get there, maybe having an option makes sense for overlays, etc...
Regarding the "things should be functions" vs "things should be operators" discussion, it should be relatively trivial to have built-in functions and have the compiler translate those to opcodes under the hood. This is very common in C/C++ compilers, and means you can add support for new hardware as it improves without having to mangle the language.
a := random( range )
...is much easier to read than
a :?= range
What they actually compile to can be identical.
I have an odd relationship with Spin. It drives me batshit crazy occasionally, particularly where certain operators overlap with C/C++ but have different meaning (>=, =>, >>=, =>>, ..? I can never remember which is which). I like that it's compact, but the fact that I have to hand-optimize everything, including constants, is annoying, and the inability to share objects is maddening. If I want to use serial output within multiple objects in my code, I need to jump through VAR vs DAT hoops to make it happen. It's simple to use, and great for quick tests or small projects, but I have a hard time taking it seriously for anything of any scale. And to those about to jump in with, "but BST, or OpenSpin, or..." - sure, but the moment I need to set up a command-line compiler for Spin I'll just go back to C.
The current compile process for P1 is not exactly a all in one go thing.
Essentially each object is compiled and stored in a container of binary objects, and as parent objects are compiled their child objects are appended (copied out of the container onto the end of the parent). The only thing a parent object knows about the child object is the public symbols and the offset to the child from the start of itself. The public symbols are stored as a binary blob along with each object in the container, and when compiling of the parent starts it slurps those public symbols into the live symbol table so things work out.
The above is a simplification of what all happens, but it represents things well enough.
It would not be very difficult to convert things so that child objects can be stored as already compiled blobs, and have link pass that just combines the stored blobs together into the final binary. In fact, I intend to do something like this for the "live compile" feature I want to implement where and editor/IDE can continuously compile the code as you are typing and give you feedback and "intellisense" like features. It's just another small step from that to having compile and link being separated.
This doesn't work, because the programmer has to provide a seed that gets modified with each call. And it may be desirable to work with multiple seeds. So how do you specify that with a simple function call?
a := rand(range, @seed)
is a bit wordy but might work. Spin's ? operator is considerably more terse.
If you're hijacking the language, you arguably don't need the @, or the range, if there's a standard default. It would also be trivial to have a built-in default seed as part of the system, so you don't need arguments at all in the default case. But now we're into function overloading, or arguments with defaults, neither of which Spin supports.
a = rand()
a = rand(@seed)
a = rand(range)
a = rand(range, @seed)
Should Spin2 support separate compilation, libraries, and linking?
Yeah, then we can get the slow compilation and link speed of C++ and all the added complication for the user.
That is to say, no.
JasonDorie,
...the inability to share objects is maddening.
True. But I was wondering...
Rather than pass object references around so that things like FDS can be used from many other objects in a program, what about a message passing system? As long as there is a instance of FDS, for example, running somewhere on can send and receive data trough some message channel/mailbox/queue whatever.
This message passing scheme could be built into the very syntax of the language. As it was in Occam and is today with XC from XMOS and the Go language. For example something like:
Receive data from a channel:
x ? somechannel
Send data to a channel:
someChannel ! y
One would pass references to someChannel rather than passing object references around.
This not only allows object reuse in a "tree" of code running in a COG but takes care of the mutual exclusion required when talking between COGS.
I think random should be removed from the language altogether.
The random number generators supplied with most languages are notorious for not being very good. I'm not sure the one in the Propeller is any better.
Who says it has to be perfect? For things like getting a robot out of a corner or shuffling a selection of tunes, a poor RNG is still better than none at all. And the one built into Spin is pretty good -- even better with Chip's RealRandom object.
Comments
Every instruction must take at least two clocks, even AUGx.
RDLUT/WRLUT occur on phase one. Instruction read occurs on phase two. So, RDLUT always takes three clocks, from any execution mode.
Is this how the RAM pathways are hooked up?
1. Sometime ago, the subject of replacing ifnot with unless came up. Perl uses unless, and it's very natural, in that it's the way we would say things in conversation. However, things get complicated when you add an else clause to the mix. In that scenario, I think that ifnot is less confusing.
2. In Spin, the limits of the repeat <var> from <expr> to <expr> are recomputed every time through the loop. It would be nice if there were a shorthand alternative that allowed the <expr>s to be computed just once at the beginning. The side effects of recomputing the limits every time through can not only be confusing, but in many cases unwanted.
3. I would go along with single-line if/else statements, in both prescript and postscript forms, but not as a substitute for the ternary operator.
-Phil
Just for PNut, right? That's the only reason you're using Delphi I hope.
Sorry, man but I strongly disagree with you on the Ternary operator. It's invaluable and clean. I am baffled why you hate them.
I also feel that it absolutely needs to be the normal ? : set and not some weird keyword variant. The random operator can just become a keyword thing. I thousands of spin files I have run through openspin for testing, I've run into once or twice at most.
Ken,
pnut uses delphi and pnut needed some updates for this go around.
PropBASIC uses FreePascal/Lazarus, which is open source, and rather more portable than Delphi.
(eg there is a FreePascal on RaspPi)
which can be Delphi compatible in many cases, especially in command line pgms.
How does PNUT compile in FreePascal ?
Agreed. I don't care about the form. If we want just the "?"", fine. SPIN has lots of operators, and that's a strength IMHO. Adding one for this won't change things much.
But, I'm in favor of adding this. It's just too common of a program flow to omit.
The streamer also has a pathway to the hub via RFxxxx/WFxxxx operations.
That's right.
Seconded. Guess I do care about the form a little.
To allow the common syntax of the Ternary the random operator could just change to ?? instead of ? and all is fine.
with :=,+=,-=, <=,>=,#<,#> and some others it should be understandable for a user and as well for a parser.
As for build in commands for things like i2c, serin/out, spi and all those nifty protocols, I am strongly opposed to add this to the compiler/interpreter.
Like the P1, the P2 will use soft devices, it is one of the main advantages. The language should just be that, the language. Everything else can be loaded as needed, like in spin1.
Just make objects out of it, most of them will not even need a cog, just inline pasm in a object.
Thankfully @Roy stated that building the runtime depending on the actual program is possible, I think this is a really needed feature, sort of removal of unused methods from a object, removal of unused byte codes and implementation from the used interpreter.
This will shrink down the size of a program+spin2 and that is basically a very good thing.
Defining the language (and so the interpreter) as small and lean as possible and not filling up a complete cog, could enable us to not just having some stack in the cog but maybe user defined data.
some peek and poke for the interpreter-cog your program is actual running on would be nice.
Enjoy!
Mike
That is exactly the horrible tangled mess of unnecessarily obfuscated source that makes me loath ternary operators.
Like Phil's example:
c := (a < 5 ? 5 : a) * 10
What is that line noise supposed to mean?
if a < 5 c := 50 else c := a * 10I know, that is 4 lines instead of one. So? It's clear and immediately obvious.
@Roy, I feel such things should be functions/methods not keywords of the actual language.
I find the one line with ternary version easier to read.
I agree about random being a function/method (built in?) instead of a keyword. That's more what I meant anyway. I think Spin keywords should be paired down to the real language stuff, and other stuff should be a kind of standard library or instrinsics type stuff.
Mike, will you be writing Cobol programs in Spin2?
I look forward to programming with a ternary operator. It makes selection really easy.
Complex because it another syntactic knot to entangle anyone new to programming. It's another two weird symbols/operators to have to assimilate.
Redundant because we have "if"..."else'' which already does the job. Why do we need another way to make a selection?
IF a < 5 THEN c := 50 ELSE c := a * 10 ENDIF or c := MAX ( a * 10, 50)EDIT: Heater .. didn't see your post ..
Maybe replace with ? with ?> and <? , both as prefix operators.
-Phil
Ah, never thought of that. Moves me from "not opposed" to in favor.
Yes, I am looking forward to compile COBOL to run on a P2. My favorite COBOL at this time is GnuCobol, a 'transpiler' producing C source out of COBOL.
Sadly GnuCobol - by now - needs dynamic linking and PropGCC does just support static linking on the P1. My hope is that PropGCC for P2 will support dynamic linking, but I also try to convince the GnuCOBOL guys to support 100% static linked programs, by now they use both, but still need some stuff linked dynamic.
Most of my P1 projects are running out of code space and for that reason I advocate for a modular design of Spin2 compiler and interpreter, so just needed things end up in the binary.
Enjoy!
Mike
-Phil
Yes.
Also a valid point, but they are not mutually exclusive.
Certainly simple single-build buttons are easy to use, but separate linking allows a mix of languages, and as David says, on 512k+ address space, this could give significant speed gains. Easy to do both.
large FONT tables, for example, can be late-linked, no need to re-compile those every time..
Some users want to run P2 tools on quite feeble platforms, so design-for-speed matters more than on a big PC box.
...is much easier to read than
What they actually compile to can be identical.
I have an odd relationship with Spin. It drives me batshit crazy occasionally, particularly where certain operators overlap with C/C++ but have different meaning (>=, =>, >>=, =>>, ..? I can never remember which is which). I like that it's compact, but the fact that I have to hand-optimize everything, including constants, is annoying, and the inability to share objects is maddening. If I want to use serial output within multiple objects in my code, I need to jump through VAR vs DAT hoops to make it happen. It's simple to use, and great for quick tests or small projects, but I have a hard time taking it seriously for anything of any scale. And to those about to jump in with, "but BST, or OpenSpin, or..." - sure, but the moment I need to set up a command-line compiler for Spin I'll just go back to C.
Essentially each object is compiled and stored in a container of binary objects, and as parent objects are compiled their child objects are appended (copied out of the container onto the end of the parent). The only thing a parent object knows about the child object is the public symbols and the offset to the child from the start of itself. The public symbols are stored as a binary blob along with each object in the container, and when compiling of the parent starts it slurps those public symbols into the live symbol table so things work out.
The above is a simplification of what all happens, but it represents things well enough.
It would not be very difficult to convert things so that child objects can be stored as already compiled blobs, and have link pass that just combines the stored blobs together into the final binary. In fact, I intend to do something like this for the "live compile" feature I want to implement where and editor/IDE can continuously compile the code as you are typing and give you feedback and "intellisense" like features. It's just another small step from that to having compile and link being separated.
a := rand(range, @seed)
is a bit wordy but might work. Spin's ? operator is considerably more terse.
-Phil
a = rand()
a = rand(@seed)
a = rand(range)
a = rand(range, @seed)
All of these are possible in C++.
That is to say, no.
JasonDorie, True. But I was wondering...
Rather than pass object references around so that things like FDS can be used from many other objects in a program, what about a message passing system? As long as there is a instance of FDS, for example, running somewhere on can send and receive data trough some message channel/mailbox/queue whatever.
This message passing scheme could be built into the very syntax of the language. As it was in Occam and is today with XC from XMOS and the Go language. For example something like:
Receive data from a channel: Send data to a channel:
One would pass references to someChannel rather than passing object references around.
This not only allows object reuse in a "tree" of code running in a COG but takes care of the mutual exclusion required when talking between COGS.
The random number generators supplied with most languages are notorious for not being very good. I'm not sure the one in the Propeller is any better.
-Phil