C to Spin Preprocessor

[Dave Hein]

I am working on a program that converts C code to Spin.· I think I understand how Spin handles pointers, but it seems a little confusing to me.· I have attached a small peice of C code and the Spin version that is produced by my preprocessor.· Could someone look at it to make sure I'm doing the pointer stuff correctly?

Thanks,
Dave

[RossH]

Hi Dave,

Looks ok - but it is easy enough to tell. Why not just run them both and find out? I'm not at home at the moment or I'd try running your C code with Catalina.

Beware that C pointers are not as simple as most people seem to believe. C and SPIN are quite similar in the way they handle pointers to simple data types (bytes, words, longs), but C implements general purpose pointer arithmetic that works for ANY data type (i.e. ptr + 1 is not always the same as (int)ptr + 1). Implementing this in SPIN may get a bit complex. But it can certainly be done.

However, pure syntactic translation of C to SPIN will get you part of the way to C on the Propeller, but it will never get you all the way there. Almost immediately scoping is going to cause you problems. C has external scope, file scope and block scope for identifiers, whereas SPIN has only file scope and method scope. This means you will have name collisions in almost any C progam more complex than a few lines (especially for simple-minded programmers like me who tend to re-use the same names for multiple identifiers - such as 'i' for all for all 'for' loop variables - and rely on block scope to keep them out of trouble!). Names will also cause you problems for other reasons. You could fix the scope issue by just renaming things - I tried to do it this way in early versions of Catalina - but almost immediately you run into the SPIN limit on the length of identifier names. This is one reason I had to abandon support for using the Parallax SPIN compiler and use Homespun instead.

But the bigger problems are mostly at the higher level. For example, how are you intending to handle macros, conditional compilation and include files? C programs absolutely depends on these - although they used to be considered somewhat separate, they are now as much a part of the definition of the C language as the 'if' statement or the ++ operator. My suggestion here would be to use an existing C preprocessor and not try to do this yourself (there are many available, and most of them are quite independent of the compilers they are written to work with). But a bigger problem is how to handle libraries and program linking. SPIN has no concept of binary linking, and no-one has written a general purpose binary linker for the Propeller - this was one of the major problems I had to overcome with Catalina. Since writing a decent binary linker is almost as big a job as writing a compiler, I chose to take the 'easy' opton and link at the source level instead (much easier!). You are welcome to use the source-level linker that Catalina uses (it is called "bind") - but be aware this part of Catalina is GPL'd.

Ross.

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

[Dave Hein]

Ross,

Thanks for the suggestions.· My intent is to handle a subset of the C language.· The preprocessor will not handle #include, structs and floating point variables.· It will allow for simple #defines that translate into a constant, but I won't be able to handle macros.· My preprocessor can build a list of variables and their types, so it can distinguish between a char, short or long pointer.··Thanks for pointing out the·issue·about how C handles pointers.· I'll·make sure I handle the pointer arithmetic correctly.

The conditional compile stuff may be tricky.· I should be able to add support for simple #ifdef and #if directives.·· However, I probably won't allow anything too complex.

Dave

[Cluso99]

Dave: The #ifdef and #if directives are available in both homespun and bst. This may be the route to take as it maybe easier in the long run. If users are going to use your code, they probably will be happy using a free compiler. We used both in ZiCog, although now use a few of bst features, and it works on unix & macs.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

[Nick Mueller]

> Almost immediately scoping is going to cause you problems.

That could be solved by using new names. Will result in unreadable code, but as long as it compiles ...


Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

[RossH]

Nick,

Yes, it can be done. But it is not really a good option. C identifiers are required to be 64 characters and are case sensitive. Parallax only allows about 30 characters and names are not case sensitive. Your only real choice is to assign sequential numbers as names (and then of course you then have to keep track of them all). But this makes the generated SPIN code virtually unreadable, and makes debugging both the compiler itself and the resulting SPIN code very difficult.

I orignally went down this road with Catalina, but I kept uncovering more and more things I had to try and squeeze into the name to make it work - such as the filename (to ensure that the variable names with file scope in different files did not collide). I eventually just ran out of characters (and patience!) and moved across to Homespun.

Of course if you are limiting yourself to a language which is effectively SPIN but with C-like statements and syntax then you don't need to worry about some of these things.

Dave's translator efforts are to be applauded. After all, the idea has been raised many times in these forums but no-one has (as far as I know) actually tried to do it. But I also think that any such translator has to implement enough C to make it an attractive alternative to SPIN.

Ross.

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

[Nick Mueller]

> But this makes the generated SPIN code virtually unreadable,...

No doubt about that. And I forgot about the case-unawareness in SPIN. A few less chars for identifiers are OK, as long as one gets a warning if identifiers arent unique anymore.
And for the unreadability: The translator won't emmit nice-looking code anyhow, I guess. And I wouldn't bother to look at it as long as it works.

Anyhow, a limited set would be good enough for starts.


Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

[jazzed]

Dave Hein said...
I am working on a program that converts C code to Spin. I think I understand how Spin handles pointers, but it seems a little confusing to me. I have attached a small peice of C code and the Spin version that is produced by my preprocessor. Could someone look at it to make sure I'm doing the pointer stuff correctly?

Thanks,

Dave

Writing some generalized C to Spin conversion is a nice way to dig into Spin.
I've also considered this, but was discouraged by all the nay-sayers :)

Having a tool would be handy. If nothing else it can help others with C background ease into Spin.

One line in your last method bothers me: ptr := @BYTE[str][ i]
I've never tried it, but it seems to me that taking the address of BYTE anything would not work.
I would write it simply as: ptr := str+i

As Ross mentioned, the type does not enforce the right address in Spin, so you will find that
LONG[ptr+n*4] would be used for the nth long. LONG[ptr][ n] might work, but that confuses me.

[heater]

"If nothing else it can help others with C background ease into Spin."

This part I don't understand. Firstly, a small subset of C with a bunch of odd restrictions is not going to appeal to C programmers. Secondly, if the resulting Spin code is unreadable and not much related to how one would have written the program directly in Spin it does nothing to help people jump from C to Spin.

Seems to me the task is pretty much equivalent to writing a C compiler anyway.

Sorry if this make me a "naysayer" but I don't get the motivation here. Still many have the same problem with my Z80 emulation efforts. What can I say:)

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

[RossH]

@all,

I try never to be put off by "naysayers". I count something worthwhile if I can look back on it later and feel proud that I did it - even if no-one else appreciates it. I usually learn things in the process that I would never otherwise have known, and I also usually have some fun along the way.

The world may not need another C compiler - or a Z80 emulator - but it sure as heck needs more people with the skills that can only be aquired by trying to create such things.

Ross.

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

[Dave Hein]

Thanks for all the great suggestions.· They are very helpful.· My intent for the preprocessor is to serve as a language translating tool, and not to be a full compiler.· The goal is to produce readable Spin code that looks similar to the original C with variable names that are identical, or at least very similar to the original variable names.

Actually my real motivation is to learn Spin.· This seems like a fun and useful way to do it.· The comment about using "str + i" instead of @BYTE[str][ i] is a valid one.· The original C code was &str[i].· The preprocessor knew that str was declared as a "char *" in C, so it used the BYTE command.· If the original C was written as "str + i" the preprocessor would have kept it as is.

My plan to limit the scope of the C source may cause problems, but it's the only way that I can ensure that the generated Spin code looks similar to the original C.· Othewise, I'll have to create artificial names and C features such as structures will look very different in Spin.· I do plan on adding floating point in the future, but not in the initial version.

I want to handle #define's in C, because these will translate into Spin CONstants, which are very useful.· However, I will have to limit the scope of the #define's that can be used.· I haven't figured out the best way to handle #if and #ifdef at this time.

Dave

[jazzed]

Sorry for the OT

@heater,

You are apparently serving a "market" with Z80 stuff. Nothing wrong with that :)
The size of that market as measured by participants may refute the nay-sayers.
Of course winning the 2010 Propeller Project popularity contest might help that.

In the end, self satisfaction with one's achievements is more important than others opinions.

Please understand that I have great respect for what you are capable of doing.
If that is not clear, I apologize.

[heater]

You a right Jazzed. I forget that when I started on the Z80 thing it was just as a personal interest learning exercise. I have been amazed at the amount of interest it has generated here which was totally unexpected.

So, don't pay so much attention to us naysayers and as Nike says "Just do it".

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