search

zeroflag / punyforth

Forth inspired programming language for the ESP8266
Other
410 stars 43 forks source link

Port to ESP32 #19

Open loboris opened 7 years ago

loboris commented 7 years ago

Not an issue, but are there any plans to port punyforth to ESP32 ?

zeroflag commented 7 years ago

It would be good. But I don't think esp-open-rtos supports the esp32 at this moment. If it will, then adding esp32 support to punyforth won't be difficult.

An other option is to drop rtos and port only the bare-metal parts of punyforth. A contributor ported punyforth to the BeagleBone Black similarly.

So, there are definitely plans to do so, but it is not yet decided how, and when.

loboris commented 7 years ago

Thank you for the reply. I don't see why using esp-idf (which uses FreeRTOS) would be a problem. I'm very interested in porting to ESP32, I'll try to do it myself.

Best regards.

zeroflag commented 7 years ago

Cool, esp-idf should work too. Let me know if you have any questions.

craiglindley commented 6 years ago

I would really like to see Punyforth ported to the ESP32 for two reasons: 1- Much more dictionary space to work with for larger programs 2- Many more GPIO pins for connecting to hardware. If Punyforth were ported to the ESP32 I would probably stop building projects in the Arduino IDE and use it exclusively

zeroflag commented 6 years ago

I made an attempt with esp-idf. After cutting out some pieces, punyforth compiled and started on an esp32. However it fails when the assembly code tries to call C functions from RTOS. Currently call0 is used for doing this but esp-idf functions are compiled in a way that they use RETW instruction instead of RET. The RETW indicates that the function is a windowed function which is supposed to be called with call4, call8 or call12 instead of call0.

Basically there are two ways to call subroutines, one where the windowed hardware automatically saves some registers by rotating the register window and an other where register windows are not used (call0).

I tired to replace call0 with call8 and call12 but didn't work. This needs more investigations as I not completely familiar with the Xtensa architecture.

klapauciusisgreat commented 4 years ago

Do you have a snapshot of what you were trying it with ?

I'm tempted to look at the micropython setup and how it's compiled, cf. https://github.com/micropython/micropython/issues/5178

But if you already got down that path and got stumped, I'm probably no help either.

klapauciusisgreat commented 4 years ago

Do you think it's worth it to try and see if any issues you saw are fixed, since the last update was about 18 months ago?

I'm trying this right now, but before I spend too much time barking up the wrong tree: when you tried it, did you just copy punyforth into the esp-idf example directory, and then started to follow the build instructions/conventions there ? There's a fair amount of churn in the paths and naming of esp/rtos functions. If that's the wrong way to go about it, or there are other big changes that need to happen first, please let me know.

klapauciusisgreat commented 4 years ago

OK, I gave this a try - after commenting out a bunch of functions whose API completely changed and will require some larger changes [1], I ended up with something that compiles but does not link:

Either I leave the ldflags alone and then get lots of fatal warnings about dangerous relocations (probably because the binary is pretty large, beyond 512K I guess).

Or, I specify 

LDFLAGS += -mtext-section-literals

and get the linker error "undefined reference to `main'".

I'm really a noob concerning the xtensa architecture, so I'm stuck here. I'll poke around a bit more but if someone with more insight can point me to the correct path that might speed up any resolution.

[1] Seems to me that the esp32 port would probably be another arch and not a small patch of the esp8266 arch.

Jos-Ven commented 4 years ago

Hi,

When Gforth is compiled there are also many errors. No one seems to bother about them until they are fatal. At the end of the compilation you get a success message so everyone knowns the compilation succeeded.

I am not a C guru so I cannot help you out. It seems "undefined reference to `main'" occurs when the main() function does not exist in the program

Jos

From: Klapaucius Sent: Monday, June 1, 2020 7:07 PM To: zeroflag/punyforth Cc: Subscribed Subject: Re: [zeroflag/punyforth] Port to ESP32 (#19)

OK, I gave this a try - after commenting out a bunch of functions whose API completely changed and will require some larger changes [1], I ended up with something that compiles but does not link:

Either I leave the ldflags alone and then get lots of fatal warnings about dangerous relocations (probably because the binary is pretty large, beyond 512K I guess).

Or, I specify

LDFLAGS += -mtext-section-literals

and get the linker error "undefined reference to `main'".

I'm really a noob concerning the xtensa architecture, so I'm stuck here. I'll poke around a bit more but if someone with more insight can point me to the correct path that might speed up any resolution.

[1] Seems to me that the esp32 port would probably be another arch and not a small patch of the esp8266 arch.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.