What would be "gold" is if all objects that are predominatly PASM would have their PASM written in such a way it could be easily compiled and extracted as a binary blob for use with C and other languages.
This is something we started looking at in propforth; it might be handy for folks to interactively code and debug snippettes of assembler etc (one would not even have to know much about forth per se).. The thing was the the interfaces need to be defined. This means everybody (using the standard) has to agree. Sal chose a method that was logical for him, he didn't have the time for discussion by committee. We might be able to look at this again if we ever get the current release out.
Yes I mean something like that. If you can the whole spec down to less than one page:)
The spec itself occupies only about 3 to 5 of those pages. If you can do one in one page, I'd be happy to read it! But this document is intended to be completely "stand-alone" - i.e. not only to contain the spec itself, but also an explanation of why it exists, why it is constructed of various layers, and also provide an explanation and rationale behind each service in each layer (since they can be used independently). Finally, it provides not just code "snippets" but fully documented and compilable examples (in Spin/PASM).
However, I do also agree with prof_braino. There is little hope for such an initiative until more people come to realize the potential benefits. Ultimately I think this will happen, but people need to come to this conclusion themselves. You cannot simply force it down everyone's throat.
My purpose in publishing was is to simply draw together many of the things we discussed in the original thread and just "get it out there" to get new people thinking about the ideas (which are not just mine, by the way - many came from the discussions in the original thread, and include several things I wish I had thought of but didn't! However, I decided in the end not to include any individual authorship or acknowledgment - including my own).
The final answer (which might well be either slightly or completely different) would probably need to get some kind of "official" backing from Parallax before some of the members of these forums would ever accept or support it. At present, this seems unlikely - but it may happen in future once Propeller 2 development begins to fragment the way the Propeller 1 development has. This is something that I believe is inevitable, although some people seem to think otherwise.
I've never been very good at capitalizing things when I'm programming. My screen reader (and most of the ones I've used in the past) do make an effort to distinguish case, but a lot of times, it doesn't work as well as it should. Thus, I've gotten extremely lazy on capitalizing things. I could live with something like the sap standards. I.E. if the variable is supposed to be multiple words, then each first letter is capital, and everything else is lowercase. So, F_Add is how the previous example would show up.
I've not (yet) looked at the specs, but if this is how they're written, I can work with that.
Unfortunately, enforcing spacing is extremely tough for me, since I have to manually count spaces, (or I suppose I could set tabs), since when I'm just reading code as a document, I do not get any feedback at all on how many spaces there are between letters/starts of lines. Again, I understand why folks like such things, and I can work with such requirements, but there's a reason I avoid python.
Just my $0.02.
Oh, and case sensitive operating systems drive me nuts. I use osx in the show me capitals, but don't require them mode. It works better when trying to find things with ls or rm.
Usually, if there's going to be a distinction between local and global variables, then it's usually signified by something like L_Var_Name for local vars, and G_Var_Name for global ones. This gives you an overall picture of variables at a glance, without having to read the code at all.
Admittedly, I rarely follow this sort of thing when I'm programming for myself, but for something that is supposed to be for others, this makes perfect sense, and it's only the addition of a single letter (well, two if you count the underscore) so it won't eat a lot of variable space.
I want to change my previous entry
Global variables should be identified by type, starting with a single lower case letter, and type declarations should all be upper case, eg. :
WORD type - wNumberOfColors
LONG type - lColorsUsed
BYTE type - bBlue
Local Variable - lvBallColor
@softcon - It is always nice to know the data type at a glance, not just whether it is global or local. Local variables and parameters are always of the LONG data type and can be assumed as such, whereas global variables can either be WORD, LONG, or BYTE data types.
For the last couple of days, I have been altering some of my stepper driver code to enable it to be used as an object. For the most part, I have been trying to bring it up to the Gold Standard specification, but as you can see from my posts in this thread, I do not agree with the specification 100%. With the exception of a little minor specification rule breaking, this code is starting to look pretty good. I did notice that the first paragragh of the specification mentions that exceptions may exist on an object to object basis. When I am finished with this rewrite of my code, I would like to submit it for Gold Standard review. Is there a specific process for submitting an object for Gold Standard review, or do I just dump it into the OBEX for random processing?
Bruce
EDIT: Perhaps for those objects that are written with the Gold Standard in mind, maybe there should be a link on the OBEX page, for uploading an object for Gold Standard review. Just a thought.
...
Finally, I would discourage method names in an object from beginning with something common to all methods in the object. I'm referring to the floating-point objects, in particular, where all the public method names begin with "F". This is redundant when invoked externally. "f.add" conveys just as much information as "f.fadd" without the redundancy.
-Phil
Sorry, really late to this party [8^) This bugged me too, so when starting F32 I tried renaming everything, even knowing it would break compatibility...of course it turns out the compiler will not let you name a routine the same as an assembly command, and MUL is reserved, even though it doesn't actually do anything. So, yeah, annoying but necessary. [8^)
Comments
This is something we started looking at in propforth; it might be handy for folks to interactively code and debug snippettes of assembler etc (one would not even have to know much about forth per se).. The thing was the the interfaces need to be defined. This means everybody (using the standard) has to agree. Sal chose a method that was logical for him, he didn't have the time for discussion by committee. We might be able to look at this again if we ever get the current release out.
Yes I mean something like that. If you can the whole spec down to less than one page:)
The spec itself occupies only about 3 to 5 of those pages. If you can do one in one page, I'd be happy to read it! But this document is intended to be completely "stand-alone" - i.e. not only to contain the spec itself, but also an explanation of why it exists, why it is constructed of various layers, and also provide an explanation and rationale behind each service in each layer (since they can be used independently). Finally, it provides not just code "snippets" but fully documented and compilable examples (in Spin/PASM).
However, I do also agree with prof_braino. There is little hope for such an initiative until more people come to realize the potential benefits. Ultimately I think this will happen, but people need to come to this conclusion themselves. You cannot simply force it down everyone's throat.
My purpose in publishing was is to simply draw together many of the things we discussed in the original thread and just "get it out there" to get new people thinking about the ideas (which are not just mine, by the way - many came from the discussions in the original thread, and include several things I wish I had thought of but didn't! However, I decided in the end not to include any individual authorship or acknowledgment - including my own).
The final answer (which might well be either slightly or completely different) would probably need to get some kind of "official" backing from Parallax before some of the members of these forums would ever accept or support it. At present, this seems unlikely - but it may happen in future once Propeller 2 development begins to fragment the way the Propeller 1 development has. This is something that I believe is inevitable, although some people seem to think otherwise.
Ross.
I've not (yet) looked at the specs, but if this is how they're written, I can work with that.
Unfortunately, enforcing spacing is extremely tough for me, since I have to manually count spaces, (or I suppose I could set tabs), since when I'm just reading code as a document, I do not get any feedback at all on how many spaces there are between letters/starts of lines. Again, I understand why folks like such things, and I can work with such requirements, but there's a reason I avoid python.
Just my $0.02.
Oh, and case sensitive operating systems drive me nuts. I use osx in the show me capitals, but don't require them mode. It works better when trying to find things with ls or rm.
Constants should all be upper case letters with an underscore to seperate main segments, eg. :
- RED_RUBBER_BALL
Local variables should be identified by a prefix of a pair of lower case letters, eg. :- Local Variables - lvBallColor
Global variables should be identified by type, starting with a pair of lower case letters, and type declarations should all be upper case, eg. :- WORD type - wdNumberOfColors
- LONG type - lnColorsUsed
- BYTE type - chBlue
Functions should start with an upper case letter and each main segment should start with another upper case letter, eg:- PUB GetTheCurrentColor
Just my opinionBruce
Admittedly, I rarely follow this sort of thing when I'm programming for myself, but for something that is supposed to be for others, this makes perfect sense, and it's only the addition of a single letter (well, two if you count the underscore) so it won't eat a lot of variable space.
Global variables should be identified by type, starting with a single lower case letter, and type declarations should all be upper case, eg. :
- WORD type - wNumberOfColors
- LONG type - lColorsUsed
- BYTE type - bBlue
- Local Variable - lvBallColor
@softcon - It is always nice to know the data type at a glance, not just whether it is global or local. Local variables and parameters are always of the LONG data type and can be assumed as such, whereas global variables can either be WORD, LONG, or BYTE data types.Bruce
It may be self-serving of me to say so, but it would be nice if the autodoc formatting were part of the GS specs.
-Phil
Yes, I agree, because there needs to be a good help system and good documentation, and your autodoc looks like it would fill that need.
Bruce
For the last couple of days, I have been altering some of my stepper driver code to enable it to be used as an object. For the most part, I have been trying to bring it up to the Gold Standard specification, but as you can see from my posts in this thread, I do not agree with the specification 100%. With the exception of a little minor specification rule breaking, this code is starting to look pretty good. I did notice that the first paragragh of the specification mentions that exceptions may exist on an object to object basis. When I am finished with this rewrite of my code, I would like to submit it for Gold Standard review. Is there a specific process for submitting an object for Gold Standard review, or do I just dump it into the OBEX for random processing?
Bruce
EDIT: Perhaps for those objects that are written with the Gold Standard in mind, maybe there should be a link on the OBEX page, for uploading an object for Gold Standard review. Just a thought.
I found the answer here: http://www.parallaxsemiconductor.com/support/goldstandard
Jonathan