Right,

About a year ago (well september '99) I started asking questions about a Palm OS port for FPC. A few people made some noise, but no one had any time to do anything, including myself!! I'm a consultant now, and I spend a lot of time away, and have a Laptop, so I'm now brimming with enthusiasm (and evenings) to begin the port!!

What I've done so far :

1. bought a book on 68k assembler (must read it sometime ;)
2. d/l the source for the Amiga port, and after a lot of hair tearing, got FPC1.02 to compile it (mainly due to poor documentation concerning the conditional defines required - I hope ;) (GDB;M68K;DBX, I believe OTTOMH)
3. taken a good look at Pila (Palm Assembler) with a view to using this as the Assembler.
4. looked ant what RTL there was on the M68K port page.. started again from scratch, borrowing the units that a guy called Swartjes (sorry, can't remember first name) did for a Macintosh Pascal Compiler (Think Pascal 4.X)

I'm currently looking at the SysTrrap mechanism, as this will in effect deliver the 'RTL' through calls to the Palm OS API.

I plan to get Palm OS 2.0 compatibility first (I own PalmPilot Pro), then move to 3.0. I'm not planning to move past 3.1 till there's a major change, as this is as high as I own (Visor).

Anyone who wants to help is welcome, but this is at a very early stage.. I have nothing that even vaguly compiles yet.

I don't have access to d/l the latest version of the RTL, but if sombody (Florian/etc) could email me a copy of the Palm specific stuff, that would be a great time saver.

Further more - how is the new compiler backend going? Is it ready for a 68K port? Has anyone got any plans to do this?

And while I'm at it - is anyone else working on a PalmOS port?? DOn't want to double up work!!

Thanks,

Matt

My last info is that Transmeta never will release a "native" Crusoe processor. The Cursoe always will need i386 machine code.

I'll do, but I don't think that anything changed the last year ...

Further more - how is the new compiler backend going? Is it ready for a 68K port? Has anyone got any plans to do this?

The status of the new back end is:
- the cg is rewritten to allow an easier support of other processor thought the generic cg which should make porting much more easier isn't written yet. But it isn't necessary that the m68k uses this generic cg. The i386 cg doesn't use it either. Adapting the 0.9.5 m68k cg to the new cg style
shouldn't be that much work.

And while I'm at it - is anyone else working on a PalmOS port?? DOn't want to double up work!!

Not as far as I know.

Dear Matt and other concerned:

I will be interested to see how your work progresses on the Palm pilot port.

I know you are focusing on the PALM stuff, but keep in the back of your mind
that the Intel ARM processors and the new Transmeta processors are coming
and they will need to be attended to as well.

Since someone did a 68K port, that person would have the most experience at isolating those things in the compiler and RTL that would allow the port to proceed
to any target processor, whether on PALM or other processor. (ARM and TRANSMETA)

In any case,

The focus should be at documenting those areas that require the processor specific stuff
and then creating the cross compiler.

Mark Diener

On which system ? Linux ?

-> The linux unit execXXX() and fork functions do exactly this:

  ID=Fork()
  if ID=0 then
    begin
    //Child
    exec(something)
    end
  else
    begin
    // Parent continues execution.
    WaitPID(ID,@ExitStatus,WNOHANG);
    end;

Have a look at the examples in the docu of the linux unit.

See above.

A similar system is possible on Windows.

Have a look at the TProcess implementation on the FCL (unit process) it allows to do this and much more in a platform-independent way.

Michael.

Fork/Clone on Linux, and let the child execute another process.

Fork/rfork on FreeBSD, and idem.

If you are running Linux then the shell command might work for you. (Just append an & after the command name)

Matt

In a message dated Tue, 31 Oct 2000 11:05:36 AM Eastern Standard Time, md writes:

<< A concepts I cannot resolve:

Is there any way to have one process execute another totally different process without having
to wait for the spawned process to terminate before continuing on?

Exec( ) style functions will create a child and wait for the child to terminate before
continuing execution. What I am looking to do is to create a completely different process
and have the Exec( ) function return as soon as the new process is started, not when it terminates.

One idea is to have the child process daemonize itself so that it spawns its own child. The daemonized process
will then return to the orignal parent, thus allowing it to continue execution.

I am looking for nothing shared between the original process and the spawned process. Even the child executable
is actually a separately compiled program.

Any ideas?

Mark Diener

A concepts I cannot resolve:

Is there any way to have one process execute another totally different process without having
to wait for the spawned process to terminate before continuing on?

Exec( ) style functions will create a child and wait for the child to terminate before
continuing execution. What I am looking to do is to create a completely different process
and have the Exec( ) function return as soon as the new process is started, not when it terminates.

One idea is to have the child process daemonize itself so that it spawns its own child. The daemonized process
will then return to the orignal parent, thus allowing it to continue execution.

I am looking for nothing shared between the original process and the spawned process. Even the child executable
is actually a separately compiled program.

Any ideas?

Mark Diener

Florian:

If transmeta will use i386 instructions, then that is one less port that will be required. I know ARM processors
will require a port.

Mark