Re: The Future of Euphoria

new topic     » goto parent     » topic index » view thread      » older message » newer message
rkdavis said...

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 smile

Pete

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu