The Propeller IS NOT an 8-bit microcontroller, it is a 32-bit microcontroller that truely operates on 32 bits at a time.
Refer to page 3 or the datasheet.
Section 1.3.1. 32-bit Multicore Architecture
Also, on page 22
Section 6.4. - Propeller Assembly Instruction Table
The Propeller Assembly Instruction Table lists the instruction’s 32-bit opcode, outputs and number of clock cycles.
I just did a text search for "8 bit" on the wikipedia page for the Propeller Microcontroller and the only search result was this:
"The Spin language is a high-level programming language. Because it is interpreted in software, it runs slower than pure Propeller assembly, but can be more space-efficient: Propeller assembly opcodes are 32 bits long; Spin directives are 8 bits long, which may be followed by a number of 8-bit bytes to specify how that directive operates. Spin also allows avoiding significant memory segmentation issues that must be considered for assembly code."
The instructions for Spin are 8 bit and for assembler are 32 bits.
Okay. Are the assembler instructions processed 32 bits at a time by the interpreter?
The Wiki article says nothing about assembler instructions.
Usually assembler is first language of a micro.
Assembly is the first language of the Propeller as well. Out of reset, the Propeller runs assembly code from the ROM. That assembly code implements the Spin byte code interpreter which starts running the Spin program that is in hub memory.
"The Spin language is compiled by the Propeller Tool software into tokens that are interpreted at run time by the Propeller chip’s built-in Spin Interpreter. The Propeller Assembly language is assembled into pure machine code by the Propeller Tool and is executed in its pure form at run time. "
So why does Spin always have to run before you use assembler?
Is that just a workaround to shut off the interpreter?
There are 8 cogs or cores and each is a 32 bit processor.
The spin Interpreter is a 32 bit assembler program that runs (executes) in a cog/core. It's purpose is to fetch 8 bit bytecodes that then execute a number of 32 bit assembler instructions to perform what that bytecode means.
Thank you David. Our posted crossed. I was writing while you were.
"Assembly is the first language of the Propeller as well. Out of reset, the Propeller runs assembly code from the ROM. That assembly code implements the Spin byte code interpreter which starts running the Spin program that is in hub memory."
I think we've got it here. Big question to get this cleared up.
'After reset". How does an assembler program start up? Will the interpreter see it's assembler and shut off?
It should be compiled and in there and just start running. Turn the chip on. Program runs.
Unless the ROM spin interpreter ALWAYS starts up.
I have been confusing startup time with execution time. I guess once the Propeller starts up if the program is running Assembler
without being interpreted the execution time should be normal not slow like Spin.
The Spin interpreter starting up and then staying out of the Assembler execution is different than staying on and
interpreting the assembler code.Is that what it does?
This is from the datasheet.There is no Assembly run time section.
3.2.
Run-Time Procedure
A Propeller Application is a user program compiled into
its binary form and downloaded to the Propeller chip’s
RAM or external EEPROM. The application consists of
code written in the Propeller chip’s Spin language (high-
level code) with optional Propeller Assembly language
components (low-level code).
Code written in the Spin
language is interpreted during run time by a cog running
the Spin Interpreter while code written in Propeller
Assembly is run in its pure form directly by a cog. Every
Propeller Application consists of at least a little Spin code
and may actually be written entirely in Spin or with
various amounts of Spin and assembly. The Propeller
chip’s Spin Interpreter is started in Step 3 of the Boot Up
Procedure, above, to get the application running.
Once the boot-up procedure is complete and an
application is running in Cog 0, all further activity is
defined by the application itself. The application has
complete control over things like the internal clock speed,
I/O pin usage, configuration registers, and when, what
and how many cogs are running at any given time. All of
this is variable at run time, as controlled by the
application.
If you want a listing you can use forum members PropTool equivalents (with some extras). Search for bst (Brads Spin Tool) and homespun, written by Brad Campbell and Michael Park respectively.
FYI, here are the Spin byte codes that PropGCC uses to get its assembly code running:
'' here is the spin code to switch to pasm mode
'' removed a load of the constant 0 and replaced it with cogid
.byte 0x3F ' Register op $1E9 Read - cogid
.byte 0x89
.byte 0xc7 ' memory op: push PBASE + next byte
.byte 0x10
.byte 0xA4 ' load PAR with Stack address
.byte 6
.byte 0x2C ' CogInit(Id, Addr, Ptr)
.byte 0x32 ' Return (unused)
Spin has features taken from a variety of languages including Pascal, C, and Basic. Like C, it's very close to the actual hardware with many of the operators and built-in statements 1-1 with the Propeller's instructions.
When processor runs across Spin it is bytecodes and is interpreted.
When it runs across assembler it is compiled machine code and is executed.
Taking a look at listing file would answer that.
Is that how it works?
Not exactly. The compiler translates the spin instructions into bytecodes and the assembly instructions into longs (32 bits). All of this is downloaded to HUB RAM, and an assembler bytecode interpreter running in a cog (aka core) reads the bytecodes and executes the assembly code required to perform the bytecode function. If the program has an assembly code section then a spin COGINIT instruction is executed, which downloads the assembly code to another cog that executes that assembly code.
Refer to Page 18 of the Propeller Manual.
Step 3 of the Boot Up Procedure:
"3. If either step 2a or 2b was successful in loading a program into the Main RAM, and a suspend command was not given by the host, then Cog 0 is reloaded with the built-in Spin Interpreter and the user code is run from Main RAM."
Spin is INTERPRETED so it needs and interpreter.
From the next section - Run-Time Procedure:
"Code written in the Spin language is interpreted during run time by a cog running the Spin Interpreter while code written in Propeller Assembly is run in its pure form directly by a cog. Every Propeller Application consists of at least a little Spin code and may actually be written entirely in Spin or with various amounts of Spin and assembly."
Refer to Page 18 of the Propeller Manual.
Step 3 of the Boot Up Procedure:
"3. If either step 2a or 2b was successful in loading a program into the Main RAM, and a suspend command was not given by the host, then Cog 0 is reloaded with the built-in Spin Interpreter and the user code is run from Main RAM."
Spin is INTERPRETED so it needs and interpreter.
From the next section - Run-Time Procedure:
"Code written in the Spin language is interpreted during run time by a cog running the Spin Interpreter while code written in Propeller Assembly is run in its pure form directly by a cog. Every Propeller Application consists of at least a little Spin code and may actually be written entirely in Spin or with various amounts of Spin and assembly."
Oops. I guess I was wrong. It doesn't come out of reset running the Spin interpreter. It comes out of reset running the loader and then later the Spin interpreter. In any case, it's running the Spin interpreter by the time any user code is run so the user code must start by executing Spin byte codes. Thanks for clarifying.
Spin was envisioned as the main programming language of the Propeller. Partly because of the limited RAM of the cogs, assembly was seen as the language for writing very high speed routines, mostly low-level I/O drivers. Spin is actually quite fast (and compact) and very suitable for 90% of programs. It was quite a few years after the Propeller was introduced before a C compiler was available (then C++ and BlocklyProp). Although the C compilers will compile directly into Propeller instructions, this is of limited usefulness because of the limited RAM available. By default, the output of the compiler(s) is either to a modified Propeller instruction set or to a compact form of the same (CMM - compact memory mode) both of which are interpreted by a small routine loaded into the cog.
Computer Architecture is the overall design and structure of the computer ... how do the various pieces work together. Are there separate memories for instructions and data or are they both in the same memory? If separate, are the memories laid out differently ... maybe bytes for data and 32-bit words for instructions?
The Propeller is a Von Neumann architecture with data and instructions in the same memory. From the viewpoint of the Spin interpreter, it's also Von Neumann. The smaller PICs are Harvard architecture with the data memory byte oriented and 12-bit or 14-bit wide instruction memory.
This is from Assembly Language Primer for the Absolute Beginner.
"SPIN
Spin is the higher level, interpreted language, native to the Propeller. All propeller programs contain at least the bare minimum SPIN program required to start the Propeller running, and hand control off to an assembly language program.
In this guide, we will work with simple assembly language programs that operate as a sub-program to a main SPIN program, followed by assembly language programs that only need SPIN to get started."
Looks like 'assembly language programs that only need SPIN to get started' are as close as you are going to get to an assembly program
Looks like 'assembly language programs that only need SPIN to get started' are as close as you are going to get to an assembly program with the Propeller.
Comments
The Propeller IS NOT an 8-bit microcontroller, it is a 32-bit microcontroller that truely operates on 32 bits at a time.
Refer to page 3 or the datasheet.
Section 1.3.1. 32-bit Multicore Architecture
Also, on page 22
Section 6.4. - Propeller Assembly Instruction Table
The Propeller Assembly Instruction Table lists the instruction’s 32-bit opcode, outputs and number of clock cycles.
"I don't know who "they" are" All that in the post is from Wiki article.
Fortran is one of the 'Big Four' early programming languages. So it it hard to write anything with it not
have a little bit of Fortran in it.
I just did a text search for "8 bit" on the wikipedia page for the Propeller Microcontroller and the only search result was this:
"The Spin language is a high-level programming language. Because it is interpreted in software, it runs slower than pure Propeller assembly, but can be more space-efficient: Propeller assembly opcodes are 32 bits long; Spin directives are 8 bits long, which may be followed by a number of 8-bit bytes to specify how that directive operates. Spin also allows avoiding significant memory segmentation issues that must be considered for assembly code."
https://en.wikipedia.org/wiki/Parallax_Propeller
Sounds like nothing is going to happen until the interpreter processes it a byte at a time.
That is what it looks like it is saying to me.
Anybody know what they mean by Propeller has 'computer architecture'?
Sounds a little different than the usual microcontroller description of Von Neuman or Harvard architecture.
Looked it up and it would seem Harvard and Von Neuman are types of computer architecture.
So I guess Wikipedia guy just put something in there to finish description.
Thank you Genetix
The instructions for Spin are 8 bit and for assembler are 32 bits.
Okay. Are the assembler instructions processed 32 bits at a time by the interpreter?
The Wiki article says nothing about assembler instructions.
Usually assembler is first language of a micro.
Figured it out.
From the datasheet.
"The Spin language is compiled by the Propeller Tool software into tokens that are interpreted at run time by the Propeller chip’s built-in Spin Interpreter. The Propeller Assembly language is assembled into pure machine code by the Propeller Tool and is executed in its pure form at run time. "
So why does Spin always have to run before you use assembler?
Is that just a workaround to shut off the interpreter?
The spin Interpreter is a 32 bit assembler program that runs (executes) in a cog/core. It's purpose is to fetch 8 bit bytecodes that then execute a number of 32 bit assembler instructions to perform what that bytecode means.
"Assembly is the first language of the Propeller as well. Out of reset, the Propeller runs assembly code from the ROM. That assembly code implements the Spin byte code interpreter which starts running the Spin program that is in hub memory."
I think we've got it here. Big question to get this cleared up.
'After reset". How does an assembler program start up? Will the interpreter see it's assembler and shut off?
It should be compiled and in there and just start running. Turn the chip on. Program runs.
Unless the ROM spin interpreter ALWAYS starts up.
I have been confusing startup time with execution time. I guess once the Propeller starts up if the program is running Assembler
without being interpreted the execution time should be normal not slow like Spin.
The Spin interpreter starting up and then staying out of the Assembler execution is different than staying on and
interpreting the assembler code.Is that what it does?
This is from the datasheet.There is no Assembly run time section.
There is a 'Compile' in Tool. It compiles.
When processor runs across Spin it is bytecodes and is interpreted.
When it runs across assembler it is compiled machine code and is executed.
Taking a look at listing file would answer that.
Is that how it works?
'' here is the spin code to switch to pasm mode '' removed a load of the constant 0 and replaced it with cogid .byte 0x3F ' Register op $1E9 Read - cogid .byte 0x89 .byte 0xc7 ' memory op: push PBASE + next byte .byte 0x10 .byte 0xA4 ' load PAR with Stack address .byte 6 .byte 0x2C ' CogInit(Id, Addr, Ptr) .byte 0x32 ' Return (unused)Not exactly. The compiler translates the spin instructions into bytecodes and the assembly instructions into longs (32 bits). All of this is downloaded to HUB RAM, and an assembler bytecode interpreter running in a cog (aka core) reads the bytecodes and executes the assembly code required to perform the bytecode function. If the program has an assembly code section then a spin COGINIT instruction is executed, which downloads the assembly code to another cog that executes that assembly code.
Refer to Page 18 of the Propeller Manual.
Step 3 of the Boot Up Procedure:
"3. If either step 2a or 2b was successful in loading a program into the Main RAM, and a suspend command was not given by the host, then Cog 0 is reloaded with the built-in Spin Interpreter and the user code is run from Main RAM."
Spin is INTERPRETED so it needs and interpreter.
From the next section - Run-Time Procedure:
"Code written in the Spin language is interpreted during run time by a cog running the Spin Interpreter while code written in Propeller Assembly is run in its pure form directly by a cog. Every Propeller Application consists of at least a little Spin code and may actually be written entirely in Spin or with various amounts of Spin and assembly."
Computer Architecture is the overall design and structure of the computer ... how do the various pieces work together. Are there separate memories for instructions and data or are they both in the same memory? If separate, are the memories laid out differently ... maybe bytes for data and 32-bit words for instructions?
The Propeller is a Von Neumann architecture with data and instructions in the same memory. From the viewpoint of the Spin interpreter, it's also Von Neumann. The smaller PICs are Harvard architecture with the data memory byte oriented and 12-bit or 14-bit wide instruction memory.
Thank you all very much.
All the answers were clear and understandable.
What the Propeller is has come into focus better.
Does anybody know where the Assembly examples are?
An assembly template would be helpful. I think somebody wrote part of one above.
I will go find the Object something and look there.Can never remember what is called. Object Exchange?
Happy Holidays!
It's called the OBEX, and there is a link to it at the top of the forum.
Thank you Kwinn
Will take a look at some of the Assembly programs.
—▷ https://forums.parallax.com/discussion/download/52004
Programming the Parallax Propeller using Machine Language, By desilva
—▷ https://forums.parallax.com/discussion/96594/machine-language-tutorial/p1
Will look at this in the morning.
"SPIN
Spin is the higher level, interpreted language, native to the Propeller. All propeller programs contain at least the bare minimum SPIN program required to start the Propeller running, and hand control off to an assembly language program.
In this guide, we will work with simple assembly language programs that operate as a sub-program to a main SPIN program, followed by assembly language programs that only need SPIN to get started."
Looks like 'assembly language programs that only need SPIN to get started' are as close as you are going to get to an assembly program
with the Propeller.
Thank you Potatohead
Is that email still good in the manual?
Thank you David Betz
Guess it takes a little repetition with me for it to take.
This is a very difficult device for me to nail down.
I think I can kiss 'load literal to register' goodbye with the Propeller. Same for W register or accumulator.
Looks like the 32 bit instructions are 'multi' instructions.
Parallax was headed that way with their SX SASM.
Explanations of the memory are difficult because it's a moving target.
Main memory and cog memory.
Manual seems to concentrate on cog memory so maybe you start there.
Will keep reading that manual and maybe something will come into focus.
MOV register, #value
Also, there's no need for a special W register, since all registers are W registers!
-Phil