25 Jul
2023
25 Jul
'23
1:41 p.m.
Hi all, I'm looking for a 16-bit big-endian Unix-like development
environment with a reasonably new C compiler and a symbolic debugger.
And/or, a libc with source code suitable for a 16-bit big-endian environment.
Rationale: I've designed and built a 6809 single board computer (SBC) with
8K ROM, 2K I/O space for a UART and block storage, and 56K RAM. It's a
big-endian platform and the C compiler has 16-bit ints by default. I've
been able to take the filesystem code from XV6 and get it to fit into
the ROM with a hundred bytes spare. The available Unix-like system calls are:
dup, read, write, close, fstat, link,
unlink, open, mkdir, chdir, exit, spawn
and the spawn is like exec(). There is no fork() and no multitasking.
I've got many of the existing XV6 userland programs to run along with a
small shell that can do basic redirection.
Now I'm trying to bring up a libc on the platform. I'm currently trying
the libc from FUZIX but I'm not wedded to it, so alternative libc
recommendations are most welcome.
There's no debugging environment on this SBC. I do have a simulator that
matches the hardware, but I can only breakpoint at addresses and single-step
instructions. It makes debugging pretty tedious! So I was thinking of
using an existing Unix-like platform to bring up the libc. That way, if
there are bugs, I can use an existing symbolic debugger on the platform.
I could use 2.11BSD as the dev platform but it's little-endian; I'm worried
that there might be endian issues that stop me finding bugs that will arise
on the 16-bit 6809 platform.
As for which libc: I looked at the 2.11BSD libc/include and there's so
much stuff I don't need (networking etc.) that it's hard to winnow down
to just what I need. The FUZIX libc looks good. I just came across Elks
and that might be a possible alternative. Are there others to consider?
Anyway, thanks in advance for your suggestions.
Cheers, Warren
References:
XV6: https://github.com/mit-pdos/xv6-public
FUXIZ: https://github.com/EtchedPixels/FUZIX/tree/master/Library
Elks: https://github.com/jbruchon/elks/tree/master/libc
25 Jul
25 Jul
8:07 p.m.
Warren - can not help you other than some thoughts/pointers for some next
steps.
1. https://www.noicedebugger.com/ - it's not FOSS and you have to buy
it. No idea how good it is.
2. OS9 was a Unix-like system for the MC6809 back in the day -- maybe
look for tools for that.
3. http://www.compilers.de/vbcc.html is a full ISO C99 C compiler that
is very portable and targets a number of 8-bit and 16-bit processors
including the MC6809
4. WRT to the symbolic debugger, the issue will be 8/16-bit and
big-endian. There were numerous ports of Mark Linton's dbx (it should be
on the 4.2 BSD - tape it was his thesis). Dbx was the predecessor to gdb
and was used to make a number of MC68K debuggers such as the original ones
at Masscomp and Sun. But address space is likely to be an issue since Mark
wrote it for a vax originally.
5. Since the MOS6502 was so ubiquitous and it is also big-endian since
its "parent" was the MC6800 (Moto developed the MC6809 as the MC6800 follow
on, in response to it when Peddle and team left Moto to build the MOS6501
and MC6502). So you might look for tools for it and retarget - there are
numerous "C 6502" tool kits in the wild. There are simulators that I know
about and often they have an embedded, but I never looked for a pure
debugger. https://github.com/unoCamel/6502-Debugger claims its a
debugger but I think it more of simulator.
6. I believe that https://lng.sourceforge.net/ had a debugger in it,
which might be place to start - it was suppose to target a couple of
processors like the 6502
7. Check out: https://en.wikipedia.org/wiki/GNO/ME GNO github sources
<https://streaklinks.com/BmKLhG2tLawMsD3xiAz5mkdq/https%3A%2F%2Fgithub.com%2FGnoConsortium%2Fgno>
which
was a UNIX clone for the Apple-II
ᐧ
ᐧ
ᐧ
On Tue, Jul 25, 2023 at 3:44 AM Warren Toomey via COFF <coff(a)tuhs.org>
wrote:
Hi all, I'm looking for a 16-bit big-endian
Unix-like development
environment with a reasonably new C compiler and a symbolic debugger.
And/or, a libc with source code suitable for a 16-bit big-endian
environment.
Rationale: I've designed and built a 6809 single board computer (SBC) with
8K ROM, 2K I/O space for a UART and block storage, and 56K RAM. It's a
big-endian platform and the C compiler has 16-bit ints by default. I've
been able to take the filesystem code from XV6 and get it to fit into
the ROM with a hundred bytes spare. The available Unix-like system calls
are:
dup, read, write, close, fstat, link,
unlink, open, mkdir, chdir, exit, spawn
and the spawn is like exec(). There is no fork() and no multitasking.
I've got many of the existing XV6 userland programs to run along with a
small shell that can do basic redirection.
Now I'm trying to bring up a libc on the platform. I'm currently trying
the libc from FUZIX but I'm not wedded to it, so alternative libc
recommendations are most welcome.
There's no debugging environment on this SBC. I do have a simulator that
matches the hardware, but I can only breakpoint at addresses and
single-step
instructions. It makes debugging pretty tedious! So I was thinking of
using an existing Unix-like platform to bring up the libc. That way, if
there are bugs, I can use an existing symbolic debugger on the platform.
I could use 2.11BSD as the dev platform but it's little-endian; I'm worried
that there might be endian issues that stop me finding bugs that will arise
on the 16-bit 6809 platform.
As for which libc: I looked at the 2.11BSD libc/include and there's so
much stuff I don't need (networking etc.) that it's hard to winnow down
to just what I need. The FUZIX libc looks good. I just came across Elks
and that might be a possible alternative. Are there others to consider?
Anyway, thanks in advance for your suggestions.
Cheers, Warren
References:
XV6: https://github.com/mit-pdos/xv6-public
FUXIZ: https://github.com/EtchedPixels/FUZIX/tree/master/Library
Elks: https://github.com/jbruchon/elks/tree/master/libc
300
days inactive
300
days old
1 comments
2 participants
participants (2)
-
Clem Cole -
Warren Toomey