Forum TI-Planet.org

I'm starting a new project, porting the Ndless toolchain to webassembly, improving the firebird emscripten port, making a TI Lua API emulator and assembling all that into a web IDE that runs completely in the browser.

I started to port the toolchain, "arm-none-eabi-ld -v" works in webassembly, I don't know if the actual linking works yet. Also cross-compiling from x86_64 to webassembly with a target of arm-none-eabi is kind of complicated.

I'll also probably have to let GCC emit assembly files, since you can't fork and call binutils in webassembly....

Also on my list are improvements to Ndless, like dynamic linking, ELF and dlopen() support, but that is a topic for another day.

I'll post progress updates in this thread.

Interesting idea

Have you thought about contributing this effort to TI-Planet's open source Project Builder? It could be a module just like the CE C/C++ toolchain :

See: https://tiplanet.org/pb
Source code (which I need to update): https://github.com/TI-Planet/Project-Builder

That's quite an ambitious set of goals

A single note so far:

Also on my list are improvements to Ndless, like dynamic linking, ELF and dlopen() support, but that is a topic for another day.

Watch out, there's a very good reason why Ndless goes through genzehn for generating final binaries targeting the calculator, instead of using ELF on both the computer side as a work format and the calculator side: the sheer bloat thereof, be it for the generated programs or for the ELF loader itself, to a lesser extent. It was attempted before, but the results are often poor to terrible: in some circumstances, very simple ELF programs can swell to dozens of KBs. That's not acceptable, and this is the reason why ELF never went beyond the prototype stage for the Nspire series (on the calculator side, again).
bFLT supports dynamic linking but has the annoying limitation of a maximum of 254 shared libraries. See https://blog.tangrs.id.au/2012/04/07/bf ... ion-notes/ .

Adriweb wrote:Interesting idea

Have you thought about contributing this effort to TI-Planet's open source Project Builder? It could be a module just like the CE C/C++ toolchain :

See: https://tiplanet.org/pb
Source code (which I need to update): https://github.com/TI-Planet/Project-Builder

Cool, I didn't know that was a thing. That way I don't even have to make a custom website layout or code editor .

Lionel Debroux wrote:That's quite an ambitious set of goals

A single note so far:

Also on my list are improvements to Ndless, like dynamic linking, ELF and dlopen() support, but that is a topic for another day.

Watch out, there's a very good reason why Ndless goes through genzehn for generating final binaries targeting the calculator, instead of using ELF on both the computer side as a work format and the calculator side: the sheer bloat thereof, be it for the generated programs or for the ELF loader itself, to a lesser extent. It was attempted before, but the results are poor to terrible: in some circumstances, very simple ELF programs can swell to dozens of KBs. That's not acceptable.
bFLT supports dynamic linking but has the annoying limitation of a maximum of 254 shared libraries. See https://blog.tangrs.id.au/2012/04/07/bf ... ion-notes/ .

For the projects that I made the ELF object file was always very small, because newlib and other libraries weren't included. To make the size difference smaller I want to support compressed ELF files, like ZEHN is compressed. Also static linking on the calculator directly in memory removes the need to include newlib on the ELF file, but would make the linker itself larger. If using ELF proves impractical, I'll make an updated version of ZEHN. Thankfully versioning support is included in ZEHN, so backwards compatibility can be kept.

An improved version of Zehn is probably the way to go, indeed. You should discuss with Vogtinator

How can I contact him? I only know his Github, and that doesn't allow messages, and couldn't find him here. Or should I just create an issue in the Ndless repo?

On IRC, #ndless-dev of the EFNet server, for quick chats, but maybe a GitHub issue would be better indeed