Re: The Future of Euphoria
- Posted by petelomax Mar 31, 2017
- 2888 views
might be worth at least seeing exactly what would need to be done.
OK, this is a quick summary of the very first step I needed to get things going on the linux port:
You can actually and very easily try this out yourself (on either windows or linux) to get a feel for things.
Change constant suppressopRetf in p.exw to 1
compile this using "p p -nodiag -norun test.exw" (and you can put that suppressopRetf back to 0 now):
--format PE32 --format PE64 format ELF32 --format ELF64 constant hw = "hello world\n" #ilASM{ [PE32] xor ebx,ebx push -11 -- nStdHandle (p1) call "kernel32","GetStdHandle" mov edx,[hw] mov ecx,[ebx+edx*4-12] -- length shl edx,2 push ebx -- lpOverlapped (NULL) push esp -- lpNumberOfBytesWritten push ecx -- nNumberOfBytesToWrite push edx -- lpBuffer push eax -- hFile, call "kernel32","WriteFile" push eax call "kernel32","ExitProcess" [ELF32] mov ecx,[hw] mov eax,4 -- sys_write(ebx=int fd,ecx=char *buf,edx=int len) mov edx,[ebx+ecx*4-12] -- length (p3) shl ecx,2 -- raw(hw) (p2) mov ebx,1 -- stdout (p1) int 0x80 mov ebx,eax -- exitcode (p1) mov eax,1 -- sys_exit(ebx=int error_code) int 0x80 -- xor ebx,ebx -- (common requirement) [PE64] sub rsp,8*7 -- 5 params and space for target of r9, plus align mov rcx,-11 -- DWORD nStdHandle (p1) call "kernel32","GetStdHandle" mov rdx,[hw] mov qword[rsp+4*8],0 -- LPOVERLAPPED lpOverlapped (p5) shl rdx,2 -- LPCVOID lpBuffer (p2) lea r9,[rsp+5*8] -- LPDWORD lpNumberOfBytesWritten (p4) mov r8,[rdx-24] -- DWORD nNumberOfBytesToWrite (p3) mov rcx,rax -- HANDLE hFile (p1) call "kernel32","WriteFile" add rsp,8*7 mov rcx,rax -- UINT uExitCode (p1) call "kernel32","ExitProcess" [ELF64] mov rsi,[hw] mov rdx,[rbx+rsi*4-24] -- length(hw) shl rsi,2 -- raw(hw) mov rdi,1 -- stdout mov rax,1 -- sys_write(rdi=unsigned int fd,rsi=const char *buf,rdx=size_t count) syscall mov rdi,rax -- error_code mov rax,60 -- sys_exit(rdi=int error_code) syscall }
Then run filedump.exw on the resulting binary. Hopefully, using ELF binaries on arm will mean that much of the scaffolding will already be in place and only need minor tweaks. The important tab is Code, which should match [one block of] the source above (and nothing else), and of course the executable should actually run (on a suitable system).
I had the luxury of having FASM to build something very similar, I doubt there is anything quite like that for arm [??]. The other thing that can be done is find any small executables that work on the Pi and see what filedump.exw makes of them. And certainly no harm in looking at a clib/libc/glib or whatever it is called (since writing the above, I have come to the realisation it is much better to call that than use syscalls).
While it will certainly not happen overnight, it should be a realistic and achievable goal to get an extra ten lines on the above, beginning with [ARM], that actually builds (on win/lnx) and runs (on Pi).
No doubt that is a hard path to take, and no doubt some wag will say "it should be written in C" - but no points for guessing what I will point at that is written in C
Pete