Hi i'll update this thread with a thing that discovered now compiling another program.
We found that we couldn't use -std=c89 to compile...but instead i found that with --std=gnu89 it compile fine.

Maybe this info is usefull for others and for @deadwood as a workaround for this issue https://github.com/deadwood2/AROS/issues/222

@Farox,

Thanks, I'll try that. Yes, your screenshot shows that your pForth is echoing your input. That is a bug/unwanted feature I'm trying to solve. There is an echo variable in the source but it is set to zero to avoid echoing so something else is going on.

NathanH

I excluded the posix .c file because gives error (maybe need more checking) and used the Stdio i modified the makefile to compile

DEBUGOPTS = -g
CCOPTS = $(WIDTHOPT) -x c -O2 $(FULL_WARNINGS) $(EXTRA_CCOPTS) $(DEBUGOPTS)

#IO_SOURCE = pf_io_posix.c pf_fileio_stdio.c <----- commented line
IO_SOURCE = pf_io_stdio.c pf_fileio_stdio.c <------ modified and enabled line....

EMBCCOPTS = -DPF_STATIC_DIC #-DPF_NO_FILEIO

#######################################

then copied from pf_io_posix.c the function...sdSleepMillis into pf_io_stdio.c

Here is the function to copy....

cell_t sdSleepMillis(cell_t msec)
{
const cell_t kMaxMicros = 500000; /* to be safe, usleep() limit is 1000000 */
cell_t micros;
cell_t napTime;
if (msec < 0) return 0;
micros = msec * 1000;
while (micros > 0)
{
napTime = (micros > kMaxMicros) ? kMaxMicros : micros;
if (usleep(napTime))
{
perror("sdSleepMillis: usleep failed";
return -1;
}
micros -= napTime;
}
return 0;
}

About Echoing....don't know i attach a shot of the shell

@Farox,

I first tried the posix version of stdio but got an error so used the regular stdio instead and commented out .POSIX. It complained about undefined sdSleepMillis and sdResizeFile which is why I commented out those sections of code. I'll look through the posix version like you did and may be able to make it work without commenting out like you did. Do you get the echoing? For example, if you type "3 4 +" you should get a new line that says " ok". When I do it it gives me a newline with "3 4 + ok". Thanks.

NathanH

Glad that you build it, but in my case i didn't need to comment out sdResizeFile, and i also added (copied from the posix version) the
sdSleepMillis and it compile fine the pForth exe. It passes also all the tests, and i didn't noticed any problem...but i also don't know Forth and never used before, maybe you have more experience with it.

Actually you lead me to the solution. Once you confirmed that building with cmake works, I looked at cmake files and noticed that -std=c89 was commented out in them. So it was a team work

@Farox and @deadwood,

Thanks, that got passed the inline problem. Had to comment out sdResizeFile and sdSleepMillis in the source code and it compiled the pforth executable. Seems to run but the terminal echos input. Looking into fixing that. Also looking at adding custom functions to be able to call AROS library functions like I did in 32-bit parForth. Thanks, this is a great start!

NathanH

@deadwood
As allways you are right...it was so simple.

@NathanH
Forget all i was writing and follow what real developer suggest...take the original code and comment out -std=c89 in the Makefile.
All compile fine without any changes.

It's a long shot but maybe commenting out -std=c89 in the Makefile will resolve this __header_inline error?

Yeah i was getting the same error using the Makefile, probably it needs to be rewritten for Aros, your toolchain is most probably perfectly working if you already compiled some other project.
As i write before i was not able to use/modify the Makefile to build.
I have used a different method (that is already supported by the program) to build, it's using CMakelists.txt.
To use it (after you have adapted it for Aros) you have to make a new dir called "build" (for example).
Go the new created build dir and open here a new shell/terminal.
Type "cmake .." or "ccmake .." if you want to use the ncurses gui on the terminal.
And if all goes well...without errors...you can now type "make" to build the program.
Remember that i needed to adapt the CMakeLists.txt (in the main directory and the other in /csrc dir, plus i needed to copy a function from "posix/pf_io_posix.c" to "stdio/pf_io_stdio.c" (the function sdSleepMillis needed to build).

Let me know if you need more help or want the sources modified to build with CMake.

NathanH, congratulations, excellent work!

@Farox,

Did you get the same error I was getting (1st message in thread) when trying make with the makefile? If so, how did you get around it? If not, when did you create your x64 toolchain? Deadwood seemed to think thought that my build system was corrupted somehow. If you didn't get that error then there is something wrong with my compiler. I've made it from scratch three times now so not certain how a problem could have slipped in.

NathanH

@Farox,

Very cool. I'll continue to try. Thanks.

NathanH

@NathanH

I got managed to build pForth for Aros 64 bit.
I built using CMAKE (with a modified CMakelists.txt) and some changes to the sources. Plus i had to use Aros to have some things created (as it's not possible to run pforth compiled for Aros under linux...and it needs to create the .dic and the pfdicdat.h file).
I was not able to create a valid Makefile for Aros...sorry

I attach here a shot of the program running on a shell of Aros.

For the moment don't want to share my build...as i think you would try to build for yourself, as a learning experience.
If you are in trouble feel free to ask.
If you don't want to try to build...i share my build and the sources...but i prefer you try it first.

@Farox

Yes, once I got rid of the immediate errors that I was receiving with "int" I was going to work on the rest of the makefile. It does a lot of stuff that is unneeded that can easily be done in forth instead. The makefile creates a pforth_standalone executable all of which is unnecessary because it can be done in forth. All that is necessary is to get the pForth executable compiled so all of the stuff after that in the makefile can be removed.

NathanH

@Farox,

I was hoping I didn't make any silly errors simply building the compilers. Thanks for giving it a whirl. Its said to be very portable being all in C so I thought it would be a good target for my first try. Maybe not.

NathanH

Hi NathanH
For the toolchains it's fine to have both on the same partition (but obviously on different directory).
Like you write the 32 bit is on "myrepo" dir and the 64bit is on "myprojects" dir, i have also this config and its fine.

Regarding PForth i think the makefile for the Unix version need more check and adjustment (not only adding CC=...).
I tried to build using CMAKE instead of MAKE but it stopped after building a lib...need more changes probably.

Attached is a shot

Sure, its at https://github.co...v2.0.1.zip

Nathan

If you can give me a link to the source of pFort I can try to see if I get the same errors with my cross compiler setup.

Hmm the repo for 32-bit compilation needs to be a phisically separate one from the repo for 64-bit compilation. They are on different branches, so everything about them needs to be separate.