Most will easily see the "writing the result of a boolean operation to a hardware port" here.
P2.3 is just a logical port. A Read-Modify-Write was performed on the Port 2 register. And an essential part of that action, so that only bit 3 was affected, was masking. QED.
BTW, I have seen thread titles modified. How is this done? Now that Seairth has informed me that this is a well-worn debate in programming circles, I wish to change the title to something innocuous. Good Grief!
I have some really cute cat pictures I could share.
Most will easily see the "writing the result of a boolean operation to a hardware port" here.
P2.3 is just a logical port. A Read-Modify-Write was performed on the Port 2 register. And an essential part of that action, so that only bit 3 was affected, was masking. QED.
? - depends on how far you want to s-t-r-e-t-c-h the red-herring of masking I guess.
The opcode contains the BIT Address, not any mask.
Given the opcode form, the HW designers could choose to implement the MOV as a 8-bit addressable latches, as that is atomic in nature.
The 8051 routinely changes bits within bytes, where other bits can change on the same cycle.
(google HC259 for examples of how to write BITS with no 'mask', just an address & value)
It really is a matter of perspective. My perspective has been warped from so many years of dealing with (and preferring to deal with) things at a very low level.
I have some really cute cat pictures I could share.
Yes, by all means, do. Cat pictures would lend this thread some gravitas.
-Phil
LOL!
Speaking of gravitas, a niece gave us a very black long-hair adult cat last April. With the colder temperatures his mane has turned appliance gray while his face and paws remain jet black. It's a very odd look.
In fact I'm so used to C that its operators are less of a convention and more of a law of nature.
Absolutely yes. C's operators are found in C#, Java, Javascript, PHP, Lua and no doubt others.
I was a bit shocked on discovering Spin that anyone would design a language with different operators. Worse still make them similar enough to trip up the typical C, C#, Java, Javascript, PHP programmer. It's just an unnecessary pain in the neck.
In fact I'm so used to C that its operators are less of a convention and more of a law of nature.
Absolutely yes. C's operators are found in C#, Java, Javascript, PHP, Lua and no doubt others.
I was a bit shocked on discovering Spin that anyone would design a language with different operators. Worse still make them similar enough to trip up the typical C, C#, Java, Javascript, PHP programmer. It's just an unnecessary pain in the neck.
Yes, I agree. Operator consistency across languages would be a very good thing.
We should talk one of the compilers writers around here into creating the Cpin language.
Like Spin but with C style operators and precedence rules.
Oh and curly braces for block scoping rather than white space.
The compiler that I almost have a working parser for should be able to do that. You can define new operators, bracket types, etc. mid-parse. My parser will be done as soon as I finish teaching it how to parse ambiguous things like "jmp #label" and "object#constant". I found a way that should work well but haven't had time to implement it yet. Someone could write a plugin for a Cpin parser, and the backend would probably be the same as the standard Spin backend.
The only problem is that {} would then mean both block scope and block comment.
You can define new operators, bracket types, etc. mid-parse
Sounds like a recipe for chaos. Like C++ but worse. If that is possible
Those ridiculous {} and ' comments would have to go of course.
I don't think it will be quite as bad (I hope). You won't be able to override pre-existing operators (but you will be able to have prefix unary, postfix unary, and binary infix versions of the same operator, e.g. like "*ptr" and "x*y" in C). Custom operators would be untyped and generally most useful for things like letting you write "floata .+ floatb" (note the . in front of the +) instead of "f.fadd(floata, floatb)". Doing "floata .+ inta" would be just as nonsensical as "floata + inta" - there will be no automatic casting and you'll still need to do casting yourself (via a new operator). Internally, precedence is currently indicated by a float, but I hope I can find a better way to specify it in the actual external interface.
I agree, when targeting a 'Similar but subset' approach to languages, it is good to think about being able to compile the code blocks on a different host.
ie Subset is tolerable, but quirks that make a common compiler barf, are best avoided like the plague.
A Library of support functions is a workable way to manage necessary differences.
Spin is also more similar to Pascal, so another possible morph is to support FPC/Lazarus common subset.
Comments these days are widely //
Why? Would you rather see "floata + floatb", with all the problems it would come with involving automatic conversions and such? Or do you enjoy writing out floating point expressions using functional notation?
My ".+" operator's definition would be nothing more than something like this:
Also, I would definitely like to make my compiler be able to take any code relying on its extensions and convert it into standard Spin, hopefully in a way that produces an editable Spin file (i.e. no magic numbers and such) and preserves comments.
This converter could probably also be made to emit Free Pascal or C or Forth or whatever else you want, so I don't really see compatibility being a big problem.
In general compilers don't change their syntax as they parse the source code. If they did then conceivably you could start writing a module in what looks like C, continue with something that looks like Pascal in the middle and end with some Lisp.
How confusing should source code be?
I don't even like #ifdefs in C. That is mixing up two different languages. I shudder at macros
Have a look at some good old fashioned PHP server side code. HTML, with PHP interspersed, with SQL queries thrown in. Nightmare!
Still goes on of course with Javascript mixed up in HTML and CSS in web pages. eek.
Spin already does exactly that. Most Spin files start out looking like a high-level language similar to Pascal but untyped and with indentation for block delimiters, but then later turn they often turn into assembly files. I can't see why it would be any wierder if an Extended Spin file suddenly turned into Lisp or, more realistically, Forth. Of course, any Forth or Lisp or C or Pascal or whatever would be isolated in its own type of Spin block. I might allow nesting via indented anonymous Spin blocks, but if I do, I'll try to make it feel as natural as possible so you won't face problems like drowning in quotes and backslashes and escaping like you would in SQL in PHP in HTML.
My macros will not be a different language, like they are in C. They will be closer to D or Lisp macros. They will be a natural extension of the language. The parser won't know anything about them - it will just think they're normal operators or function calls. I might add #ifdef macros just for compatibility, though.
I think we can safely say I've hijacked User Name's original thread. Let's move any further discussion about this to another thread, say http://forums.parallax.com/discussion/160333/it-s-time-for-a-new-spin-compiler. The second attempt I'm working on right now currently doesn't share any code with my first attempt linked to in that thread, but I will merge them at some point, since I do still want the module loader it has. I'll try to publish what I have later this week.
Comments
P2.3 is just a logical port. A Read-Modify-Write was performed on the Port 2 register. And an essential part of that action, so that only bit 3 was affected, was masking. QED.
I have some really cute cat pictures I could share.
The opcode contains the BIT Address, not any mask.
Given the opcode form, the HW designers could choose to implement the MOV as a 8-bit addressable latches, as that is atomic in nature.
The 8051 routinely changes bits within bytes, where other bits can change on the same cycle.
(google HC259 for examples of how to write BITS with no 'mask', just an address & value)
-Phil
LOL!
Speaking of gravitas, a niece gave us a very black long-hair adult cat last April. With the colder temperatures his mane has turned appliance gray while his face and paws remain jet black. It's a very odd look.
I was a bit shocked on discovering Spin that anyone would design a language with different operators. Worse still make them similar enough to trip up the typical C, C#, Java, Javascript, PHP programmer. It's just an unnecessary pain in the neck.
Yes, I agree. Operator consistency across languages would be a very good thing.
Like Spin but with C style operators and precedence rules.
Oh and curly braces for block scoping rather than white space.
The compiler that I almost have a working parser for should be able to do that. You can define new operators, bracket types, etc. mid-parse. My parser will be done as soon as I finish teaching it how to parse ambiguous things like "jmp #label" and "object#constant". I found a way that should work well but haven't had time to implement it yet. Someone could write a plugin for a Cpin parser, and the backend would probably be the same as the standard Spin backend.
The only problem is that {} would then mean both block scope and block comment.
Those ridiculous {} and ' comments would have to go of course.
I don't think it will be quite as bad (I hope). You won't be able to override pre-existing operators (but you will be able to have prefix unary, postfix unary, and binary infix versions of the same operator, e.g. like "*ptr" and "x*y" in C). Custom operators would be untyped and generally most useful for things like letting you write "floata .+ floatb" (note the . in front of the +) instead of "f.fadd(floata, floatb)". Doing "floata .+ inta" would be just as nonsensical as "floata + inta" - there will be no automatic casting and you'll still need to do casting yourself (via a new operator). Internally, precedence is currently indicated by a float, but I hope I can find a better way to specify it in the actual external interface.
I could easily make comments user-definable, too.
"floata .+ floatb"
Makes me very nervous.
I agree, when targeting a 'Similar but subset' approach to languages, it is good to think about being able to compile the code blocks on a different host.
ie Subset is tolerable, but quirks that make a common compiler barf, are best avoided like the plague.
A Library of support functions is a workable way to manage necessary differences.
Spin is also more similar to Pascal, so another possible morph is to support FPC/Lazarus common subset.
Comments these days are widely //
Why? Would you rather see "floata + floatb", with all the problems it would come with involving automatic conversions and such? Or do you enjoy writing out floating point expressions using functional notation?
My ".+" operator's definition would be nothing more than something like this: Also, I would definitely like to make my compiler be able to take any code relying on its extensions and convert it into standard Spin, hopefully in a way that produces an editable Spin file (i.e. no magic numbers and such) and preserves comments.
This converter could probably also be made to emit Free Pascal or C or Forth or whatever else you want, so I don't really see compatibility being a big problem.
I have to think on this some more.
In general compilers don't change their syntax as they parse the source code. If they did then conceivably you could start writing a module in what looks like C, continue with something that looks like Pascal in the middle and end with some Lisp.
How confusing should source code be?
I don't even like #ifdefs in C. That is mixing up two different languages. I shudder at macros
Have a look at some good old fashioned PHP server side code. HTML, with PHP interspersed, with SQL queries thrown in. Nightmare!
Still goes on of course with Javascript mixed up in HTML and CSS in web pages. eek.
I can wait to see what you come up with.
My macros will not be a different language, like they are in C. They will be closer to D or Lisp macros. They will be a natural extension of the language. The parser won't know anything about them - it will just think they're normal operators or function calls. I might add #ifdef macros just for compatibility, though.
I think we can safely say I've hijacked User Name's original thread. Let's move any further discussion about this to another thread, say http://forums.parallax.com/discussion/160333/it-s-time-for-a-new-spin-compiler. The second attempt I'm working on right now currently doesn't share any code with my first attempt linked to in that thread, but I will merge them at some point, since I do still want the module loader it has. I'll try to publish what I have later this week.
BTW, I really like where this conversation is going. Cspin or something like that sounds marvelous. Brilliant. Law of Least Surprise.