SPIN improvements

David Betz · 2012-10-09 12:03

Roy Eltham wrote: »

David,
Sadly, that code isn't going to work right. I've just put up new code that should fix everything for you, do another svn update please.

Make sure you get r41 (r40 compiles but had a bug).

Got it! Thanks Roy! It compiles fine with no warnings. I'll try it later tonight. I'd like to try using your compiler to build all of the PropGCC cache drivers to remove dependence on bstc.

David Betz · 2012-10-09 17:05

Roy,

I started trying to integrate your Spin compiler with the PropGCC build process and ran into a feature that is needed. The PropGCC makefiles typically write their output files to a different directory from where the sources are stored. This requires us to use a -o option to explicitly specify the output filename and path. I've added a Google Code issue to cover this request.

Thanks,
David

David Betz · 2012-10-09 18:13

I seem to be running into a problem with the Spin compiler. I added the -o option to my local copy and now I'm getting the following error when I compile c3_cache.spin using the -c option:

spin -p -c -DENABLE_RAM -o include/c3_cache.dat spin/c3_cache.spin
Propeller Spin/PASM Compiler (c)2012 Parallax Inc. DBA Parallax Semiconductor.
Compiled on Oct  9 2012
Compiling spin/c3_cache.spin...
spin/c3_cache.spin(1:1) : error : Invalid object file cache_interface.OBJ

I'll attach c3_cache.spin as well as cache_interface.spin.

kuroneko · 2012-10-09 18:17

David Betz wrote: »

spin -p -c -DENABLE_RAM -o include/c3_cache.dat spin/c3_cache.spin
Propeller Spin/PASM Compiler (c)2012 Parallax Inc. DBA Parallax Semiconductor.
Compiled on Oct  9 2012
Compiling spin/c3_cache.spin...
spin/c3_cache.spin(1:1) : error : Invalid object file cache_interface.OBJ

FWIW, that's a known issue when trying to extract the DAT section(s) from an object with sub-objects. Time to re-open issue 3.

David Betz · 2012-10-09 18:19

kuroneko wrote: »

FWIW, that's a known issue when trying to extract the DAT section(s) from an object with sub-objects.

It works with bstc. This sub-object doesn't itself define any data. It's just definitions.

kuroneko · 2012-10-09 18:21

The fact that there is a sub-object is the problem here (together with -c usage).

David Betz · 2012-10-09 18:23

kuroneko wrote: »

The fact that there is a sub-object is the problem here (together with -c usage).

Do you know if Roy is working on a solution to this or do I need to find a way to work around it?

kuroneko · 2012-10-09 18:30

David Betz wrote: »

Do you know if Roy is working on a solution to this or do I need to find a way to work around it?

I added my comment to the existing (but already closed) issue (he confirmed notification). As I can't re-open it myself I guess it got forgotten. So for now I suggest you find a workaround. Hopefully Roy will take the hint from here

ersmith · 2012-10-09 18:38

David Betz wrote: »

Do you know if Roy is working on a solution to this or do I need to find a way to work around it?

One work-around might be to use spin2cpp to extract the DAT sections.

David Betz · 2012-10-09 18:40

ersmith wrote: »

One work-around might be to use spin2cpp to extract the DAT sections.

Or use #include instead of the cache_interface.spin object. All I need from there are a few defines.

David Betz · 2012-10-09 18:48

ersmith wrote: »

One work-around might be to use spin2cpp to extract the DAT sections.

Hmmm.... I just tried this and it seems spin2cpp doesn't accept the -o option. :-)

Roy Eltham · 2012-10-09 20:05

David Betz,
I'll re-look at the -c option tonight. Can you message or email me a patch of your adding of the -o option to integrate?

Roy Eltham · 2012-10-10 03:42

David,
I updated the compiler to fix the -c option, I tested with your c3_cache.spin/cache_interface.spin files and it now produces the same results as bstc does.

Were you going to send me a patch with your mods for the -o option, or are you going to make me do the work myself?

Roy

David Betz · 2012-10-10 04:07

Roy Eltham wrote: »

David,
I updated the compiler to fix the -c option, I tested with your c3_cache.spin/cache_interface.spin files and it now produces the same results as bstc does.

Were you going to send me a patch with your mods for the -o option, or are you going to make me do the work myself?

Roy

Sorry Roy, I'm on the east coast and was sleeping. :-)
I'll send my changes later this morning.

David Betz · 2012-10-10 04:42

Roy Eltham wrote: »

David,
I updated the compiler to fix the -c option, I tested with your c3_cache.spin/cache_interface.spin files and it now produces the same results as bstc does.

Were you going to send me a patch with your mods for the -o option, or are you going to make me do the work myself?

Roy

Sorry. Here's the patch.

David Betz · 2012-10-10 06:44

Roy Eltham wrote: »

David,
I updated the compiler to fix the -c option, I tested with your c3_cache.spin/cache_interface.spin files and it now produces the same results as bstc does.

Were you going to send me a patch with your mods for the -o option, or are you going to make me do the work myself?

Roy

Hi Roy,

Thanks for fixing the -c bug!! I made one more minor change which was setting the maximum length of a symbol to 32 instead of 30 and I'm now able to build the PropGCC loader without using bstc. Both the Spin code and the PASM code seem to compile and work correctly at least for the simple test of loading the propgcc/demos/fibo/xmmc demo program. However, that exercises the serial helper program which is written in Spin as well as the c3_cache.spin driver which is mostly PASM. Looks like we can probably get rid of the use of bstc in the PropGCC build process!

Thanks again!!

David

Heater. · 2012-10-10 06:47

This is excellent news. I can't use BST when building on an ARM board and juggling those .dats and .bins from the PC build was getting tedious.

David Betz · 2012-10-10 06:57

Heater. wrote: »

This is excellent news. I can't use BST when building on an ARM board and juggling those .dats and .bins from the PC build was getting tedious.

There are still other things in PropGCC that are built using bstc but fixing that is just a matter of editing some makefiles. We also have to build Roy's compiler for all three platforms and verify that everything works. I've only tried it on the Mac.

Heater. · 2012-10-10 07:15

David.

There are still other things in PropGCC that are built using bstc

I have only found I need to make .dat and .binary files when building propgcc on ARM and it falls over trying to building the loader. What have I been missing here?

Roy's spin compiler builds and runs on ARM although I have not given it much use.

David Betz · 2012-10-10 07:17

Heater. wrote: »

David.

I have only found I need to make .dat and .binary files when building propgcc on ARM and it falls over trying to building the loader. What have I been missing here?

Roy's spin compiler builds and runs on ARM although I have not given it much use.

There are some drivers in the library that need bstc I think. There are certainly demo programs that need it.

Heater. · 2012-10-10 07:20

Ah! the demos. Kind of forgot all about them.

David Betz · 2012-10-10 07:31

Heater. wrote: »

Ah! the demos. Kind of forgot all about them.

I just looked and I guess the library build doesn't need bstc so all we have to do is update the demos.

jazzed · 2012-10-10 08:05

Roy Eltham wrote: »

That's going in tonight. Just doing testing/debugging now.

Still, go add the issue on the google code site for the file list thing. It seems like it would be easy to add.

Thanks Roy.

I've added 2 issues, one for object tree output, and one for Archive file list output.
Someone may use those features someday ....

Roy Eltham · 2012-10-10 11:45

Thanks for the patch David, I applied it locally, and also changed the symbol_limit to 32. Just need to run it through the tests. I'll try to get that submitted tomorrow night (have plans for tonight after work already).

Also, thanks Steve, I'll get to those soon.

David Betz · 2012-10-10 12:13

Roy Eltham wrote: »

Thanks for the patch David, I applied it locally, and also changed the symbol_limit to 32. Just need to run it through the tests. I'll try to get that submitted tomorrow night (have plans for tonight after work already).

Also, thanks Steve, I'll get to those soon.

Thanks Roy!!!

Cluso99 · 2012-10-10 13:46

heater: (OT) What ARM board are you using?

Heater. · 2012-10-10 13:59

Cluso,

I have built all the opensource Propeller tools on a Raspberry Pi board running the Raspian version of Debian Linux (which is optimized for the floating point hardware available).

I have a bunch of ISEE IGEP boards, running Linaro. I'm sure all those builds will work fine there as well just haven't had time to get around to it. http://www.isee.biz/index.php/products/processor-boards/igepv2-board

The IGEP is not cheap but has an industrial temp spec. (down to -40C) and lots of goddies on board.

David Betz · 2012-10-10 14:16

Heater. wrote: »

Cluso,

I have built all the opensource Propeller tools on a Raspberry Pi board running the Raspian version of Debian Linux (which is optimized for the floating point hardware available).

I have a bunch of ISEE IGEP boards, running Linaro. I'm sure all those builds will work fine there as well just haven't had time to get around to it. http://www.isee.biz/index.php/products/processor-boards/igepv2-board

The IGEP is not cheap but has an industrial temp spec. (down to -40C) and lots of goddies on board.

Is there any particular reason you run these tools on the RaspberryPi? Surely, an inexpensive desktop machine is a lot faster. I almost bought a RaspberryPi but then couldn't think what I would do with it. It seems more of a curiosity than a practical machine. What is your application for it?

Heater. · 2012-10-10 14:49

David,

Is there any particular reason you run these tools on the RaspberryPi?

Because I can:)

Over the years I have seen plenty of robots carrying around honking great laptops as their "brains". There are many on YouTube.
Presumably they have Arduinos or other processors/electronics to handle all the sensor inputs, motor controls etc. Presumably those Arduinos or whatever are also programmable from the stonking great laptop being carried around.

So here's the reasoning. The honking great laptop can be replaced with an tiny, low power consumption ARM board running Linux. It provides the horse power for the "brains" part. The low level stuff is done by Arduino or our favourite the Propeller. It make sence then that the "brains" can also be used to reprogram the Propeller.

Put a Raspi board and a Prop board together and you have the whole control system in a cigarette packet sized space to fit in your robot or whatever. Complete with networking, USB etc. WIFI is only a tiny dongle away. As a bonus the whole machine is now completely self hosting. No PC required anymore. If, that is, all the Propeller tools can be got working on the ARM. Which so far they can.

For 30 dollars or so, why not do it?

As for practical, well that Pi has more processing power and disk space than the PC I was using a few years back. Well OK last centuary. There is nothing practical about being tied to a desktop machine on a particular desk.

softcon · 2012-10-10 14:56

The major advantage to this approach would be adding new languages to the propeller would become super easy.
Simply call the compiler of choice, to translate language of choice into spin code, then pass it off to the actual spin compiler, and poof, instant support for any language desired.
This is exactly how many compilers work already, acting only as a front-end then passing their output to gcc for the actual compiling. Fortran, pascal, and ada are three that work this way off the top of my head.
I'm all for this approach.

SPIN improvements

Comments