perplexed by line in keyboard.spin
Fred Hawkins
Posts: 997
line 54 of keyboard.spin (in the propeller root folder) has a longmove from @dpin to @par_keys. I can't figure out where·@dpin would be. In the DAT section there is a long called _dpin, which seems to be a horse of a different color.
And at end of the program at line 608:
What am I missing?
PUB startx(dpin, cpin, locks, auto) : okay stop longmove(@par_keys, @dpin, 4) okay := cog := cognew(@entry, @par_tail) + 1
And at end of the program at line 608:
_dpin res 1 'read-only at start _cpin res 1 'read-only at start _locks res 1 'read-only at start _auto res 1 'read-only at start
What am I missing?
Comments
That is your source for dpin's value.· It is imported via the PUBLIC nature of the start up.
_dpin is a designated location that preserves a copy of the data for later use.
Obviously, 'dpin' represents the data pin in a serial keyboard interface and 'cpin' would represent the clock pin.
Refer to the documentation notes for the remaining items within the parenthesis.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Everything in the world is purchased by labour; and our passions are the only causes of labor." -- David·Hume (1711-76)········
and
this allows you to remove the bit of assembly code that updates _dpin through _auto with the values passed in as a parameter.
·
given PUB routine(param1,param2,param3 ... paramn)
@param1 = address of first of n consecutive longs consisting of param1, param2, param3 ... paramn
Which are in the stack space if not defined elsewhere, yes? Or are they always in stack space because that's how parameters are passed?
Nevermind:
Post Edited (Fred Hawkins) : 8/22/2007 2:01:20 AM GMT
Your quote however is out of place. That is just the basic SCOPE rule of SPIN: NO OVERLOADING! NO SHADOWING!
SHADOWING:
In nearly all programming languages it is possible to define "local names" in routines, blocks, or other kinds of sections; this in fact can continue "ad infinitum" when the language supports nested "blocks" or even nested procedures.
When you write a small routine in the context of large program it would be a (minor) nuissance to avoid all the thousend global names you are not interested in. Defining a local name already existing as a (relativly) "global" name is generally accepted. The global name is just not available during the time this local definition is in effect. This has nothing to do with the cell this global name refers to. You can still access is by a pointer or an alias. It's there, but you can not "see" it, as it is SHADOWED by the local name.
SPIN does not support SHADOWING, this is ratherunusual and users did never like those restrictions although there are good reason for them, in addition to that they make the task of the compiler much easier
OVERLOADING:
But what, if those redefined names are not of the same kind? E.g. START used as a string, as an array of reals, a procedure with one parameter, a procedure with two parameters? In most languages it can be determined out of the context which of the many STARTs you are referring to. As the name START now carries many "meanings", it is called OVERLOADED.
This is also not supported by SPIN, though the compiler has SOME knowledge about the use of names (called "types"): It knows if it is:
- an I/O register
- a procedure with n parameters
- a byte, word or long cell
Post Edited (deSilva) : 8/22/2007 7:49:55 PM GMT
What am I missing [noparse][[/noparse]in the manual and support documents that explains/teaches this sort of code]?
So you might stick to fancy ideas - depending on languages you worked with formerly: Pascal? C++? Python? FORTRAN
You expect, that a "parameter" is something untouchable or that a sequence of cells in memory is an "array". Best consider everything from the machine language point of view!
Actually, my background is mostly line numbered retro BASIC, assembly (9900, 68000; both big-endian) and FORTH. Pascal always made me puke -- classic EU hairshirt. C was worse -- programming for the two-fingered, C++ was/is something for deeppocketed two-fingered, and FORTRAN was before my time.
What I think I miss about the Propeller manual is succinct summary of addressing and reference modes, both in regards to Spin and Assembly. Including assumed variable creation like what happens above as opposed to overt VAR, CON, DAT, |, : constructions. My other wish list contains (today) a binary dump and a careful discussion of run-time and compile-time behaviors.
In this particular example, I now accept that "dpin, cpin, locks, auto" are longs sequentially in memory, but I can't prove that behavior except that it apparently works dependably. The manual doesn't seem to weigh in except as I quoted it above. Left to my own, I would have and did in fact surmise that "dpin, cpin, locks, auto" were items on a stack that are consumed by the call -- Forth's stack model. Wrong again. I can now see that I will have to work hard against that particular mindset.
Another periphery complication is that in Keyboard.spin, the two routines start and startx have similiar parameters:
PUB start(dpin, cpin) : okay
PUB startx(dpin, cpin, locks, auto) : okay
One of the things that bothers me about the above longmove is how to decide which @dpin is meant. I am left with a guess at scope. But not much help in that regard is found in the manual.
Fred
its the DPIN that is "visible" for that LONGMOVE.
I think that the writers on the manual had a kind of C language in mind and expect this pre-knowledge from their readers. They where not aware (Manual Writers! Please excuse me if I am wrong!) , that
- there are MANY more MUCH MORE advanced languages, where certain high level concepts (like "true" and multi dimensional arrays) are used. C is somewhat of "general knowledge", but the "state of the art" now is 40 years A.C.
- There are many "newcomers", with mostly electronic or elementary BASIC background, who have no C experience, and do not know and do not care why compiler writers have done certain things in the past..
From my experience of teaching programming languages to students of other faculties - though it's long ago - maybe I am more aware of this...
A major problem - when adapting to observed facts, not documented in the manual - is that this may change, with versions of more advanced and optimizing compilers, e.g. there might be reasons to arrange the stack upside down, so the last local variable will have the lowest addres and the first parameter the highest...
Keeping silence had never been a good strategy, as users will (and have to!) exploit all possible features, especially in time and space restricted systems as the Prop.
Post Edited (deSilva) : 8/23/2007 7:49:06 PM GMT