If i understand you correctly, you want to work and compile on an embedded system or a thin client. But why dont you use a normal workstation/notebook to do that? To test the program you can use than your embedded system.
You also could use a VM with the limited memory specs for testing. With QEMU you propably could even emulate the CPU. So you don't need every different type of test system in physical form.
If i understand you correctly, you want to work and compile on an embedded system or a thin client. But why dont you use a normal workstation/notebook to do that? To test the program you can use than your embedded system.
You also could use a VM with the limited memory specs for testing. With QEMU you propably could even emulate the CPU. So you don't need every different type of test system in physical form.
Or use the thin client to connect to a system with more workstation specs, like a raspberry pi 4 8GB with SSD ( :-) )
At least that is what I did back in 2000, when I had to run Windows 2000 on a Pentium-I 166 Mhz with 96 MB memory. I learned how to access my corporate outlook using cygwin MUTT (saved 25MB Outlook process) and used an X(ceed) client to connect to my Linux PC at home.
I doubt you want to use TCC's assembler specifically. You want to replace GCC/binutils with TCC, right? In that case, TCC should be used as a C compiler, not an assembler. As srvaldez said, fbc already supports at&t syntax asm when generating C (it can parse inline at&t assembly (although not as well) and pass it through to C), and can tell GCC to produce att instead of intel when compiling to assemble.. It does not support compiling FB to at&t assembly without using GCC.
Recently here on the forums we were discussing how to use clang instead of gcc. Supporting other C compilers like TCC would be very nice. TCC's commandline arguments are pretty similar to GCC, so at least it wouldn't require major changes in fbc.bas. No idea how much needs to change in ir-hlc.bas
Or otherwise, look for some other intel syntax assembler.
