Windows, Linux, OSX,...?

Luis Digital · 2007-05-04 04:01

Already it has passed a lot time and we do not know anything on the version for Linux.

I have had a little free time and I have completed promise.

Somewhat interesting that I have discovered is that Parallax not even has to create a version for Linux, the version for Windows works with Wine with a small modification

Now well, using Lazarus I compiled the same program in Linux and functioned.

Then, the same old question:

When will be ready the units to compile SPIN/ASM?
Even I am willing to create an IDE free (yes gratis) for you or at least to do the intent.

Jet_aj · 2007-05-04 04:21

Cool!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
HOLY *@Microsoft%@! (sorry for the cuss, I've been trying to clean up my language)
Live, Love, Learn!
My web: www.geocities.com/jet_aj
My Car Audio site: www.jdubaudio.com

LoopyByteloose · 2007-05-04 16:14

Wow! I'll have to try WINE with Win32Forth. That's another Windows based program that keeps me in WindowsXP.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"If you want more fiber, eat the package.· Not enough?· Eat the manual."········

···················· Tropical regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan

Harrison. · 2007-05-04 21:05

I think what Luis is saying is he was able to compile the serial communication unit that Chip posted on the forums with Lazarus. It doesn't seem as if he got the standard Propeller.exe windows application to successfully communicate with a Propeller chip directly under Wine.

I managed to get the Propeller tool to enumerate the serial ports in Wine. Unfortunately it also requires a windows NT only api call to NTConnectPort which fails since Wine does not implement many ntdll.dll calls since it is largely undocumented by Microsoft. A large portion of Windows 2000+ applications (Office, etc) will not run in Wine due to the use of the NTConnectPort and other NT only api calls.

Now if Luis did get the Propeller.exe to run successfully in Wine (that is, with the built in serial communication stuff working) then I would be really happy.

Harrison

Luis Digital · 2007-05-04 22:47

Harrison. said...
I think what Luis is saying is he was able to compile the serial communication unit that Chip posted on the forums with Lazarus. It doesn't seem as if he got the standard Propeller.exe windows application to successfully communicate with a Propeller chip directly under Wine.

I managed to get the Propeller tool to enumerate the serial ports in Wine. Unfortunately it also requires a windows NT only api call to NTConnectPort which fails since Wine does not implement many ntdll.dll calls since it is largely undocumented by Microsoft. A large portion of Windows 2000+ applications (Office, etc) will not run in Wine due to the use of the NTConnectPort and other NT only api calls.

Now if Luis did get the Propeller.exe to run successfully in Wine (that is, with the built in serial communication stuff working) then I would be really happy.

Harrison

Only "serial communication unit that Chip posted on the forums with Lazarus", but also in Unix (Linux, FreeBSD, OSX, etc.)!

If NTConnectPort is not documented, why to use it?

Really I want to show that is not difficult for Parallax to do a version for Linux, like some people say.
Also it is possible to use the version for Windows with Wine if Parallax desires.

The manufacturers have to think the things two times before leaving the millions of users of Linux of last.
Imagine to have a PC as OLPC(http://www.laptop.org) using the Propeller.
And now adds DELL among others that love Linux.

Harrison. · 2007-05-04 23:06

I am sure there are various reasons why Parallax does not have the time to retarget / crosscompile the tool for linux. The current version does everything except download to the Propeller Chip under Wine. I don't think this is too much of a problem since Remy Black has written a nice python loader tool.

I have heard that the assembler / spin compiler is written in x86 assembly. While it may be possible to port to other OSes, my guess is that it probably uses some sort of windows only stuff (unless all it does is get fed with memory locations where the source to be compiled is). It may just be better to rewrite the entire compiler in some other more portable language such as C. Unfortunately this would take too much time, which is why others have started working on making their own compilers.

Harrison

Post Edited (Harrison.) : 5/4/2007 11:15:13 PM GMT

Paul Baker · 2007-05-04 23:48

I've just had a long talk with Chip about this subject and in the interest of putting this issue to rest, this is what has been decided:

Parallax will not be providing the compiler for any other platform either in IDE or library form.

We have determined that we do not want to spend the resources required to·code,·document in full detail·and technically support this endeavor. To do so would derail ongoing projects for an indefinite period of time.
We appologize to all parties that are affected by this decision.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

mirror · 2007-05-05 01:05

I respect the decision of the guys at Parallax.

The biggest problem of open-source / free software is: How do you pay your mortgage?

I know it's not quite that simple, but ... there is already enough information out there to write your own command line comipler if you so wish.

If you don't believe me, then have a look at the Gear emulator/simulator!! It has sufficient information to substantially reverse engineer the compiler to the point of a Linux/open platform tool.

I think it's a simple question of economics for Parallax. If each of the thousand people out there using Linux gave Parallax U$300 each, then Parallax could probably employ someone to write the Linux version. But then hey, you could probably pick up a copy of Windows for about that much.

And that, ladies and gentlemen, is the cruel reality of business.

Tom Bampton · 2007-05-05 02:18

I don't want to derail this thread, but I do want to say something.

Gary Preston and I will be supporting Windows, OS X and Linux with our toolchain. The eventual goal is loader, assembler, linker, emulator and at least one high level language. The assembler is complete as a prototype and production work has already started. The linker will be next, followed later by a high level language. We do not yet know what the high level language will be, but it probably won't be Spin. That of course does not prevent someone else writing a Spin compiler that targets our tool chain, we just are unlikely to do that ourselves.

We are doing this because we need the tool chain, not because we want to make a product. However, if the Parallax community has some specific thing they need it to do, we can probably do it. For example, whilst we don't particularly want to write an IDE ourselves, we could easily provide access to the entire tool chain via a cross platform library. If any of you have suggestions, feel free to suggest them. I can't guarantee they'll all be implemented, but we will at least consider them all [noparse];)[/noparse]

Anyway, I mainly just wanted to say that it's not all bleak on the non-Windows front. It will take some time to get there, but in the interim there are "many" alphas, betas and probably one or two updates to the prototype to come.

T.

Luis Digital · 2007-05-05 02:18

mirror said...
I respect the decision of the guys at Parallax.

The biggest problem of open-source / free software is: How do you pay your mortgage?

I think it's a simple question of economics for Parallax. If each of the thousand people out there using Linux gave Parallax U$300 each, then Parallax could probably employ someone to write the Linux version. But then hey, you could probably pick up a copy of Windows for about that much.

And that, ladies and gentlemen, is the cruel reality of business.

- Me too. What can I do?

- Nobody has spoken here of free Software, simply that function in Linux.
When I entered these forums was Parallax that spoke on the theme, the promise that is repeated from time to time.

- Changing some lines to the present version of Windows does not require more expenses of the ones that already is paying.

- Business, I understand.

mirror · 2007-05-05 03:33

Gary Preston and I will be supporting Windows, OS X and Linux with our toolchain. The eventual goal is loader, assembler, linker, emulator and at least one high level language. The assembler is complete as a prototype and production work has already started. The linker will be next, followed later by a high level language. We do not yet know what the high level language will be, but it probably won't be Spin. That of course does not prevent someone else writing a Spin compiler that targets our tool chain, we just are unlikely to do that ourselves.

It's a pity that Spin gets a bit of a bad wrap at times. It actually only needs a couple of things to make it a whole lot better. If a 3rd party spin tool were written, it could easily be made backwards·compatable with the current code, but with the following enhancements added:
1) Conditional compilation (#define, #ifdef, #else, #endif would probably almost·be enough).
2) Allow higher level Spin objects to access child object variables.
3) Add an object definition along the lines of
OBJ
· @MyObject : "ObjectDef"
which would define an object pointer which could·be filled in by a higher level definition.
4) Allow object assignment - to support 3.

With 2, it would be much easier to write code that used structures. Something along the lines of the following: (Sorry it looks a little wierd because I pressed enter after postadding the first line).

"DEMO.SPIN"

OBJ

  Pt : "Point"

PUB TestProgram

  Pt.x := 1

  Pt.y := 2

  Pt.Assign(1,2)    'Exactly the same as the last two lines

  Pt.x++            'This would make some people happy! And after all, Pt.x IS located in a fixed point in memory, so this doesn't break the "static linking" concept.

-----------------------------

"Point.SPIN"

VAR

  word X

  word Y

PUB Assign(xVal, yVal)

  x := xVal

  y := yVal

From my understanding of spin (all 3 weeks of it), and stepping through code with·the Gear emulator, all of these things should be possibile without any change to the on-chip spin interpreter. It's just the compiler that needs changing. The nett result could still be a statically linked program - I think.

FSRW & friends could then demo all four speed variations in a single executable!

·

Mike Green · 2007-05-05 03:45

mirror,
If I understand you correctly with #3 and #4, you're asking for a feature that is a huge source of inefficiency in languages that support it. You're basically deferring the resolution of information about the object until run-time. Sometimes it's very useful ... as in C++ and Smalltalk for example, but it costs a lot in a system with very limited memory. Stick with #1 and #2 which are both very important and are compile-time operations.

mirror · 2007-05-05 04:09

Mike Green said...
mirror,
If I understand you correctly with #3 and #4, you're asking for a feature that is a huge source of inefficiency in languages that support it. You're basically deferring the resolution of information about the object until run-time. Sometimes it's very useful ... as in C++ and Smalltalk for example, but it costs a lot in a system with very limited memory. Stick with #1 and #2 which are both very important and are compile-time operations.

I think it CAN be a huge source of inefficiency, but it doesn't HAVE top be. What I'm finding is that I want to do something like call FullDuplexSerial (FDS) from the top spin program as well as one of the child spin programs. In this case, FDS has got circular buffers so it would be wrong to define FDS in the main program as well as the child, because then you'd end up with two circular buffers. So what I'd like is for the main program to have code something like this:

OBJ
  Debug : "FullDuplexSerial"
  Child : "MyChild"
 
PUB Start
  Child.Debug := @Debug        'or something like this
  Child.SayHello

And in the child object, something like this:

OBJ
  @Debug : "FullDuplexSerial"
 
PUB SayHello
  Debug.Str(String("Hello"))

Please understand me on one thing, I'm NOT suggesting new and dispose functionality (to use the C++ terminology). The object is still statically defined and located at compile time, but once defined, then it should be able to be referenced by other objects in the system.

Maybe there's some other way to call FDS from a child as well as the main program, but I haven't yet figured out how ....

·

Tom Bampton · 2007-05-05 04:27

We have nothing against Spin. We just don't need it, which means that it would get nowhere near as much testing as the rest of the tool chain. That would lead to a sub-par compiler that I would not be happy releasing.

Windows, Linux, OSX,...?

Comments