flat assembler
Message board for the users of flat assembler.
![]() Goto page 1, 2 Next |
Author |
|
NULLPointer
How difficult would it be?
|
|||
![]() |
|
crc
No, FASM for Linux will *not* run under BeOS (I've tried!). A workaround solution could be achieved using Bochs, but it's far from a practical way to do program. I'd also like to see a native BeOS port of FASM. It'd be somewhat difficult though, as the BeOS system calls are not well documented, and it's easy to crash BeOS when invoking them outside of the C libraries.
|
|||
![]() |
|
pelaillo
Doing a native port for BeOS is not hard at all.
You will need to port very few code, all located in system.inc and in particular: basical file manipulation functions and environment function. I will do it but I have my time fulfilled for several weeks. |
|||
![]() |
|
NULLPointer
Gracias, pelaillo, vere qué hago.
|
|||
![]() |
|
NULLPointer
He estado investigando el tema de un port a BeOS pero el problema es que BeOS carece de 2 llamadas al sistema:
1. brk 2. sysinfo Alguien tiene alguna idea? Sorry for the post in spanish but i think you can understand me, don't you, Pelaillo? Thanks. Gracias. |
|||
![]() |
|
neonz
NULLPointer wrote: How difficult would it be? Well, take it and port! ![]() |
|||
![]() |
|
pelaillo
Hi neonz, I think he was doing a real question, not a rant.
NULLPointer, we will need to do some tests before getting this working, but there is always a start...
|
|||||||||||
![]() |
|
NULLPointer
If this file is from asmutils, and i'm sure it is, then i've already read it and i repeat:
there are two syscalls that BeOS miss, BRK and SYSINFO. How do i manage that??!! ![]() Any idea? Thanks for your attention. |
|||
![]() |
|
pelaillo
Code: ...
%define __NR_mmap 90
...
%assign SYS_brk SYS_exit
... We don't need to do a verbatim translation. We could write code that do the equivalent operation. For this case in particular (there's only one call to SYSINFO), Fasm needs to reserve a big chunk of memory, so we need to find some alternatives and choose a good one. A starting point could be doing tests with mmap or maybe is safer to disassembe some C written program (opensource of course to avoid infringing the law ![]() |
|||
![]() |
|
neonz
NULLPointer wrote: there are two syscalls that BeOS miss, BRK and SYSINFO. Maybe you could check out source of MenuetOS port. When fasm was ported to MenuetOS, it (mos kernel) hasn't any memory management system calls yet (AFAIK they simply defined data segment size in executable header and used fixed size buffer). |
|||
![]() |
|
NULLPointer
If fasm uses BRK to increase the data segment size, could i use malloc instead?
After all malloc is like a wrapper for brk, isn't it? Thnks. |
|||
![]() |
|
neonz
NULLPointer wrote: If fasm uses BRK to increase the data segment size, could i use malloc instead? Don't know about BeOS, but in Linux malloc() is C function that calls BRK syscall. |
|||
![]() |
|
Tomasz Grysztar
Please check out this: http://board.flatassembler.net/topic.php?p=10643
|
|||
![]() |
|
crc
It's almost working at last (see http://board.flatassembler.net/topic.php?p=10727#10727 for a longer post). I'll try to fix the single problem I've found with it and then all of us BeOS users can enjoy FASM.
|
|||
![]() |
|
crc
FASM now works perfectly under BeOS! See See http://board.flatassembler.net/topic.php?p=10763#10763 for the download (source + binary)
|
|||
![]() |
|
Ralph
I guess it's a little late for that now, but I had most of fasm ported to beos once using syscalls. If you still need it, brk is syscall number 8 on BeOS.
|
|||
![]() |
|
JohnFound
Ralph wrote: I guess it's a little late for that now, but I had most of fasm ported to beos once using syscalls. If you still need it, brk is syscall number 8 on BeOS. IMHO, pure assembly port will be better than one using clib. ![]() Regards. |
|||
![]() |
|
crc
Does BeOS have a syscall for mprotect? This is one of the few syscalls my programs rely on heavily and I haven't found any decent documentation on the BeOS syscalls yet.
|
|||
![]() |
|
Tomasz Grysztar
JohnFound wrote: IMHO, pure assembly port will be better than one using clib. I agree. But libc port gives you a working fasm on such systems, and this should make developing any pure assembly port easier. |
|||
![]() |
|
Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.
Website powered by rwasa.