Spin Bytecode Assembler

Dave Hein · 2010-07-20 13:07

Has anybody developed a list of mnemonic opcode names for the Spin bytecodes?· I was thinking of writing a simple Spin bytecode assembler, and I would like to use the standard opcode names if they have already been defined.· I have seen the table in the Wiki that describes the bytecodes, but it doesn't list opcode names.

Why would I write a Spin bytecode assembler?· The main reason is to understand how the Spin interpreter processes the bytecodes.· It seems like a Spin bytecode assembler would be fairly easy to write, and it should only take a few days.· I'm not sure if an assembler would be useful, but it would be interesting to see if there are any useful applications.

Dave

·

BradC · 2010-07-20 13:15

Sounds like a great idea. Looks like you will be the pioneer for the mnemonic names though.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"

markaeric · 2010-07-20 13:31

If you could get the assembler to run on a prop, *that* would be totally awesome!

Dave Hein · 2010-07-20 13:43

markaeric said...
If you could get the assembler to run on a prop, *that* would be totally awesome!

You're reading my mind.· I'm planning on writing it in C as a Windows/DOS app, but my main interest is to port it to Spin and run it under spinix.

Brad, I've been using the BST compiler listing as my guide, and I'll probably assign names that match up with the listing output and/or the Wiki table.· Some of the names are fairly obvious and they'll be identical to the Spin or PASM names.

Dave

Bill Henning · 2010-07-20 14:03

EXCELLENT idea!

Especially if you make a nice short set of mnemonics, and describe each opcode [noparse]:)[/noparse]

ie

LDL n - load local variable at nth index
LDG n - load global variable at nth index

perhaps with sixe suffixes (B,W,L)

The only instruction names I've seen so far have been too verbose to be used in an assembler.

Dave Hein said...
Has anybody developed a list of mnemonic opcode names for the Spin bytecodes? I was thinking of writing a simple Spin bytecode assembler, and I would like to use the standard opcode names if they have already been defined. I have seen the table in the Wiki that describes the bytecodes, but it doesn't list opcode names.

Why would I write a Spin bytecode assembler? The main reason is to understand how the Spin interpreter processes the bytecodes. It seems like a Spin bytecode assembler would be fairly easy to write, and it should only take a few days. I'm not sure if an assembler would be useful, but it would be interesting to see if there are any useful applications.

Dave

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system

Kye · 2010-07-20 15:14

That would be step towards having native C on the prop. Once you get a C-to-SPIN Bytecode converter I think you'll have something really special as you can use the best of both worlds.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

hippy · 2010-07-20 19:14

Take a look at http://forums.parallax.com/showthread.php?p=665019 and particularly BYTECODE.TXT and PropTest.PDF.

That was designed to be short but meaningful / readable mnemonics and compilable from a disassembly, and easy to generate from a HLL compiler.

An assembler would be useful because it's just so much easier to generate assembler and not have to translate to binary within any compiler. It also allows optimisation to be done on the assembler source code level.

Dave Hein · 2010-07-20 21:11

hippy,

Thanks for the pointers to your documents.· I wasn't aware of the extra unary operators and how the "effect" mode works.· I should have realized that there were a number of operators missing from the main opcode table.· How does the "reference" mode work?· What does it do?

I'm leaning more toward mnemonics that define specific memory access modes rather than a generic push and pop iwth the details in the parameters.· As an example, the opcode ldbox means LoaD a Byte with an Object offset and an indeX.· stwv would STore a Word with a Variable offset.

I'll post a table of proposed opcodes later today or tomorrow.

Dave

heater · 2010-07-20 21:22

Kye: "That would be step towards having native C on the prop."

That's an interesting take on it, I don't even consider Spin byte codes as being "native" anything.

Sadly as far as I understand the Spin byte codes are not at all convenient for creating a C to byte code compiler. That's why Parallax have this weird idea to create a "not C" language that looks like some kind of C and is intended to keep C programmers happy, which it will not.

I like this idea of a Spin assembler anyway. But I would think it needs to be able to assemble and link with PASM as well. Such that one could start PASM code from the spin assembler code.

If it was equipped with some kind of linker/locator it would be useful for creating Spin free boot loaders and all sorts of "glue" code.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Dave Hein · 2010-07-20 22:43

heater said...
Kye: "That would be step towards having native C on the prop."

That's an interesting take on it, I don't even consider Spin byte codes as being "native" anything.

Sadly as far as I understand the Spin byte codes are not at all convenient for creating a C to byte code compiler. That's why Parallax have this weird idea to create a "not C" language that looks like some kind of C and is intended to keep C programmers happy, which it will not.

I like this idea of a Spin assembler anyway. But I would think it needs to be able to assemble and link with PASM as well. Such that one could start PASM code from the spin assembler code.

If it was equipped with some kind of linker/locator it would be useful for creating Spin free boot loaders and all sorts of "glue" code.

heater,
The main limitations in Spin are the lack of a jump instruction and the inability to do function pointers.· I think everything else in C could be implemented in Spin.· Compiling directly to Spin bytecodes would allow for both the jump instruction and function pointers.· I think Parallax's idea for creating a "not C" language is to reduce the development effort, and also to make the generated Spin source look like human-generated source instead of an unreadable machine-generated source.
Dave

heater · 2010-07-20 22:52

I thought one reason that spin byte codes were not so suitable for C is the lack of unsigned integers operations. It's weird that PASM can happily deal with signed/unsigned comparisons etc but Spin cannot.

That was one of the reasons for the Parallax "not-C" language being, well, not C. As far as I remember.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Dave Hein · 2010-07-20 23:09

There is also an issue with unsigned char and short versus signed char and short.· Spin does contain a sign-extension instruction, so signed char and short can be handled with slightly less efficiency than the unsigned versions.

I don't see a real problem with implementing unsigned longs in Spin.· Adds and subtracts will produce the same result whether it's signed or unsigned.· A right-shift can be handled by using either the appropriate Spin shift operator.· The only real issue is comparing two unsigned numbers.· This requires special cases based on the most-significant bit.

Oh, there is also an issue with multiply and divide, but that can be handled with extra code as well.

RossH · 2010-07-20 23:25

@all,

Since SPIN bytecodes are "Turing complete", it is possible to compile a C program to SPIN bytecodes. The question is whether it is efficient to do so - and the answer is "probably not". The resulting programs would execute at speeds significantly slower than SPIN unless you chose to leave out some of the more complex parts of C (e.g. structures, bit fields, function pointers, floating point etc).

Having the ability to execute LMM from within the SPIN interpreter would help out a great deal here - those things that were too inefficient to be implemented in SPIN bytecodes could instead be implemented as LMM - but (as I've said in another thread) its a classic time/space tradeoff - i.e. the results would be larger - but approach LMM speeds - to the extent that LMM was used in place of SPIN bytecodes. More SPIN = smaller but slower executables. More LMM = larger but faster executables.

C is expected to be both small and fast. Unfortunately on the Prop it is difficult (perhaps impossible) to achieve both at the same time - and it's not obvious what the "ideal" tradeoff would be.

Currently SPIN is small, but C is fast. We can also have small C if we want, but it will not be fast.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

heater · 2010-07-20 23:29

Well this is all a bit beyond me now. If it is as easy as you suppose, and I might suppose too given that I see the ZPU byte codes of Zog have the same issues but it runs C anyway. Then how come Parallax were proposing the "not C" language, which basically seemed to skirt around these signedness issues?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

BradC · 2010-07-21 00:03

Dave Hein said...

Brad, I've been using the BST compiler listing as my guide, and I'll probably assign names that match up with the listing output and/or the Wiki table. Some of the names are fairly obvious and they'll be identical to the Spin or PASM names.

Nothing original in my naming. I took all the names straight out of the interpreter source code. Some of the stuff might not be intuitive to read, but the list matches the interpreter 1 for 1 so you can follow precisely what is happening when you have the listings side by side.

Remember, all the other stuff was reverse engineered prior to the interpreter being released. I did not start until after the interpreter source was posted.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"

Cluso99 · 2010-07-21 00:28

Dave: I wrote up the spin opcodes from information I found in Chip's Interpreter, Hippy's docs, and what I found also. That may help you as I think it would be a great idea. see my Faster Interpreter thread listed in the tools index link in my signature. Of course, some of these will definately require renaming to be more useful. As far as jumps go, this could be added to the interpreter.
Way to go!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz

Dave Hein · 2010-07-21 04:12

@Ross,· I think C converted to Spin bytecodes could be just as efficient as Spin if it uses unsigned char, unsigned short and signed long.· Structures should not be that inefficient.· They are basically arrays that are referenced as either byte, word or long depending on the specific type of the element that is being accessed.· Floating point should be almost the same speed whether it's Spin, C converted to Spin, or even LMM C.· bit fields may be slower than Spin -- I haven't looked at it myself.· I think there is a lot of potential in mixing Spin bytecodes and LMM.

@heater, There is no technical reason for limiting the scope of a C compiler based on Spin bytecodes.· As I said before, I think Parallax wants to preserve some the look and feel of Spin in their C implementation.· They also want to limit the amount of developmental resources required to the bare minimum.

@Brad, the compiler listing from BST is very informative, and it fills in the gaps from some of the other documents.

@Cluso, I looked at the Spin bytecode document in the thread you mentioned.· It is extremely useful.· Thanks for the information.

Dave

RossH · 2010-07-21 05:16

@Dave,

We'll probably never agree on this

To me, C without both signed and unsigned integer types is just not C. In fact it's worse than being "not C" - it is likely to fool people into thinking that the C algorithms they get off the net will run (because they compile ok) - but in fact they will be prone to mysterious failures and other problems that will be very difficult to detect and fix. Structures are certainly achievable, but perhaps a bit inefficient - but bit fields within structures would probably be really slow. As for floating point, you could certainly do them in LMM not too much slower than the current PASM implementations (e.g. with FCACHE), but in bytecodes? I think they would just be too slow to be useful.

I understand what Parallax wants to do with a C/SPIN hybrid - it is intended to mee the needs one of their key market segments (i.e. hobbyist/enthusuiast/education) - but I'm still a bit worried that (if it is not handled carefully) they may end up confusing and even alienating some other markets.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

Cluso99 · 2010-07-21 05:59

@Ross: I would think that a C style syntax for spin would be helpful for the hobbyist. This may just satisfy that market adequately.
We all know most professionals will want a real C. They may be convinced that Spin is easier for the Prop later, depending on the app of course.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz

heater · 2010-07-21 06:13

RossH:

I don't think David meant that a C compiler producing Spin byte codes would compile unsigned int as signed etc. Rather that programs that were written in C would run at Spin like speeds if they used Spin like types and would run slower if the compiler had to put in extra code for non-Spin types. At least I hope that's what he meant otherwise a lot of C code would just fail as you point out.

I have this issue with Zog. Common operations on common types are handled with single ZPU instructions which are executed in a few PASM instructions within the emulator. Some other operations like unsigned/divide modulus endup being handled by ZPU subroutines and consequently are a lot slower. So Zog can run "normal" everyday code using ints at Spin like speeds but other code will be a lot slower. Can't be helped in Zog, it's the way the ZPU instruction set is designed.

I have not even dared try any floating point code under Zog. I'm sure it will crawl along.

That's got be thinking.... Potentially I could rewrite some of those div, mod, float, subroutines as linked in my GCC and have them use a ZPU trap that gets into some PASM code in the emulator. That would be much quicker....

RossH said...

I understand what Parallax wants to do with a C/SPIN hybrid - it is intended to mee the needs one of their key market segments (i.e. hobbyist/enthusuiast/education) - but I'm still a bit worried that (if it is not handled carefully) they may end up confusing and even alienating some other markets.

I see what they want to do and I agree with you only more so.

Not only can "Not-C" be confusing to some but since I recently looked at the Arduino world for the first time I realized something even worse about Parallax's "Not-C" idea:

Anyone who as been using the Arduino has already been using real C/C++, even if they don't know it and call it "wiring" or whatever. When an Arduino user comes to "upgrade" to the Propeller or add a Propeller to their system, if they see anything that looks like C they will expect it to be like what they have on there Arduino. If they start to find it's is less capable they are going to whine about it to everyone. Not Good.

Any magazine, blog, website that "discovers" the Propeller and decides to write something about it, as we would much like them to do, will end up making comparisons with Arduino. The "Not-C" will get sneered on at this point. Not Good.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

heater · 2010-07-21 06:19

Cluso, There's the thing, having a C syntax lookalike is not good enough for hobbyists. A lot of them already have full up, industrial strength C with their Arduino's and other systems.

I should not say it here but I am impressed how the Arduino makes using C so god damn easy. At the end of the day the Arduino is quite limited but anyone who has been there will want that simplicity and no surprises.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Cluso99 · 2010-07-21 09:54

@heater: Respectfully I disagree. Spin in C's clothing would be a big addition, just as Spin in Basic's clothing would be also. This is just the syntax (i.e. Braces, switch, void, etc) but would still compile to spin bytecode. Inline pasm would most likely come too. The end result may lead to a mini-C compiler to pasm for cog only objects. Remember, a number of people have asked for the C syntax and I do not mean fully blown C.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz

RossH · 2010-07-21 10:36

@Cluso,

Respectfully, I'm afraid I have to agree with heater (you probably could have guessed I would)

Once a C neophyte has gotten over the excitement of not having to count spaces to represent program structure^*, and mastered the intricacies of the 'for' loop, the next thing they're going to do is download the source code to 'nethack' from the internet (or some other C program - everybody knows that every application ever developed has at least one open source C version on the internet somewhere - usually several of them). But almost immediately they're going to be very, very disappointed, because they won't even be able to compile it!

Ross.

^* I mean, honestly! If God had not intended us to program in C, then why did he put curly braces on every computer keyboard ever made?. I mean, what else are they good for?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

BradC · 2010-07-21 10:37

RossH said...

^* I mean, honestly! If God had not intended us to program in C, then why did he put curly braces on every computer keyboard ever made?. I mean, what else are they good for?

Commenting code in Pascal. I mean what else??

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"

heater · 2010-07-21 11:33

Hmm... Ross, if God had intended us to program in C the why did he make the curly braces in such a hard place to use? I mean AltGr-7 and AltGr-8 are just awkward when you use them a lot.

And what 's this nuts idea that "&" gets you the address of something, surely "@" is much more appropriate.

And, whilst we're at it, what's with the "->" when accessing members of a struct through a pointer? If I have an integer called "foo" then I use it's name in the code "a = foo;". If I have a pointer called "foo" and want the integer it points at I write a = *foo;

So far so good.

Now if I have a structure called "foo" I can access it's members as "foo.bar".
Therefore, if I have a pointer to a structure called "foo" I should obviously want to use "*foo.bar".
That is , dereference "foo" to get me to where it's data is and offset to it's member "bar" address.

God moves in mysterious ways.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

heater · 2010-07-21 11:37

BradC: You are cracking me up.

I'm just now getting involved in some software written in Pascal that has been under development for years and years as part of a university research project. In all the 10's of thousands of lines of code I have seen so far I think the are no more than 30 comments [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

RossH · 2010-07-21 12:32

@heater,

Comments? Luxury! When I were a wee lad, we'd have been sacked for wasting good punched cards on flamin' comments.

In fact, after a days work we had to sweep up the chads from the hollerith cards and stick them back in the holes to be used by the next shift!

But you try telling that to kid's today - and do they believe you?

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

Dave Hein · 2010-07-21 13:03

Ross,

I think you misunderstood my comments about signed and unsigned.· heater restated my position correctly.· If you want to write C code that efficiently maps into Spin you would need to use unsigned char, unsigned short and signed long.· However, the C-to-Spin compiler needs to be fully ANSI compliant, and needs to support all C types.

Using signed char will be slightly less efficient than using unsigned char.· Someone on the forum had mentioned in that past that some compilers default to unsigned when declaring a char variable.· If that is ANSI compliant then that's would be the most efficient way to configure a C-to-Spin compiler.

You should re-read my previous post again.· If you still don't understand my comments about structures and floating point I will carefully explain them to you.

Dave

heater · 2010-07-21 13:35

Dave: In ANSI C: Whether or not a simple char is considered to be signed or unsigned is left up to the implementation.

At least according to this www.ericgiguere.com/articles/ansi-c-summary.html

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

RossH · 2010-07-21 14:42

@Dave,

Yes, I had misunderstood the signed/unsigned thing originally. I was in fact recalling Parallax's original PMC document, which said it would not support 'unsigned' at all. Apologies.

Heater is right that it is up to the implementation whether "char" is signed or unsigned. I think you are still required to support them both, but naturally you would "default" to signed.

I can't see how structures can be implemented very efficiently - I have to admit I haven't bothered to figure out the exact byte codes required to read/write a field within a structure, but in LMM you can generally read or write to a field in 3 or 4 instructions. Using byte codes it seemed to require at least a couple of PUSHes (and their operands) an ADD, a POP (and its operand) and maybe a USING modifier to first calculate the address and then read/write the value. That can't be very efficient, but maybe there's a simpler method that reduces the number of byte codes required. Otherwise, even just fetching the byte codes and their operands seems to require about twice as much time as LMM PASM takes to do the whole job - and then you still have to decode and executing them.

The bit about "Floating point should be almost the same speed whether it's Spin, C converted to Spin, or even LMM C" I have to admit I just don't get. Catalina C implements all the basic floating point operations as primitives within the kernel itself - i.e. add, subtract, multiply, divide and compare each take only a few PASM (not LMM PASM, but the-genuine-article-cog PASM) instructions. What mechanism do you propose to use?

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

Dave Hein · 2010-07-21 15:36

Ross,

Efficient floating point in Spin requires a seperate cog running PASM routines.· Of course, that is cheating since it uses an additional cog, but if the cog's available then it doesn't cost anything to use it.· I also have an implementation of the basic floating point routines in LMM PASM that runs in a single cog under SpinLMM.· It's faster than pure Spin code, but it is slower than pure PASM code.

I created a small C test program that contains structures, and then I converted it to Spin.· The code is shown below.· Spin does require several operations to access struct elements, but it's not too bad.· I think it could be improved if I used byte[noparse][[/noparse]pstruct][noparse][[/noparse]p] instead of byte[noparse][[/noparse]pstruct + p].

Dave

typedef struct testS {
    unsigned char x;
    unsigned short y;
    int z;
} testT;
typedef struct test2S {
    testT istruct;
    unsigned char p;
    unsigned short q;
    int r;
} test2T;
test2T gstruct;
void CopyStruct(test2T *pstruct);
void main(int argc, char **argv)
{
    test2T lstruct;
    CopyStruct(&lstruct);
}
void CopyStruct(test2T *pstruct)
{
    pstruct->istruct.x = gstruct.istruct.x;
    pstruct->istruct.y = gstruct.istruct.y;
    pstruct->istruct.z = gstruct.istruct.z;
    pstruct->p = gstruct.p;
    pstruct->q = gstruct.q;
    pstruct->r = gstruct.r;
}

CON
' typedef struct testS
x = 0
y = 2
z = 4
' typedef struct test2S
istruct = 0
p = 8
q = 10
r = 12
VAR
  long gstruct[noparse][[/noparse]4]
PUB main(argc, argv) | lstruct[noparse][[/noparse]4]
  CopyStruct(@lstruct)
PUB CopyStruct(pstruct)
  byte[noparse][[/noparse]pstruct + istruct + x] := byte[noparse][[/noparse]@gstruct + istruct + x]
  word[noparse][[/noparse]pstruct + istruct + y] := word[noparse][[/noparse]@gstruct + istruct + y]
  long[noparse][[/noparse]pstruct + istruct + z] := long[noparse][[/noparse]@gstruct + istruct + z]
  byte[noparse][[/noparse]pstruct + p] := byte[noparse][[/noparse]@gstruct + p]
  word[noparse][[/noparse]pstruct + q] := word[noparse][[/noparse]@gstruct + q]
  long[noparse][[/noparse]pstruct + r] := long[noparse][[/noparse]@gstruct + r]