Git clone of master branch fails on macOS

[ghaerr]

Just an FYI: Cloning the source tree on a case-insensitive filesystem (the default for macOS) fails to produce a clean master branch with the following warnings:

warning: the following paths have collided (e.g. case-sensitive paths
on a case-insensitive filesystem) and only one from the same
colliding group is in the working tree:

  'Kernel/dev/ds1302_8085.S'
  'Kernel/dev/ds1302_8085.s'
  'Kernel/platform-rcbus-8085/ppide.S'
  'Kernel/platform-rcbus-8085/ppide.s'
  'Library/libs/setjmp_pdp11.S'
  'Library/libs/setjmp_pdp11.s'

I realize a system may not be able to be built on macOS but thought it would be fun to look around :)

[EtchedPixels]

All of those I think are files that shouldn't have been committed in .s form. Will take a look. It certainly won't build on a case insensitive file system because the convention is that .S is an asm file that it fed through the preprocessor produce a .s file. That's been the norm since forever.

[ghaerr]

It certainly won't build on a case insensitive file system because the convention is that .S is an asm file that it fed through the preprocessor produce a .s file.

Yes. Over at ELKS, since some developers (including myself) are using macOS, we changed the build rule so that .S files are preprocessed to a temp file then to .o:

.S.s: ;

.S.o:
    $(CC) -E -traditional $(INCLUDES) $(CCDEFS) -o $*.tmp $<
    $(AS) $(ASFLAGS) -o $*.o $*.tmp
    rm $*.tmp

.s.o:
    $(AS) $(ASFLAGS) -o $*.o $<

There's some amazing work here. I became interested in browsing some of the small 16-bit utilities, for comparison with ELKS and cloned the repo with this issue.

I realize your focus isn't 8086, does the IBM PC platform still compile/work for FUZIX? I noticed the drivers but didn't see it mentioned as a target in the master Makefile.

[EtchedPixels]

Some initial work was done but no 8086 port proper exists, just some stuff to sketch it out and compare compilers.

The libc ought to port back to ELKS as that is where much of the basic libc came from (in particular you probably want things like the malloc/free/realloc as they fixed a bunch of bugs).

[ghaerr]

The libc ought to port back to ELKS as that is where much of the basic libc came from

Yes, it looks like Fuzix libc is also from Alistair Riddoch's work and dev86 from long ago. We've done quite a bit of cleanup on it, and replaced or fixed a lot of routines. A quick look shows that your abort.c is still in trouble, unmodified from the original dev86 version, notice the arguments to kill are backwards (!):

void abort(void)
{
        signal(SIGABRT, SIG_DFL);
        kill(SIGABRT, getpid());        /* Correct one */
        pause();                        /* System may just schedule */
        signal(SIGKILL, SIG_DFL);
        kill(SIGKILL, getpid());        /* Can't trap this! */
        _exit(255);                     /* WHAT!! */
}

It also suffers from the problem of not calling the registered SIGABRT handler, if present. We replaced it with this:

#include <signal.h>
#include <stdlib.h>
#include <unistd.h>

void
abort(void)
{
    /* call registered handler if any, or die if none */
    kill (getpid(), SIGABRT);

    /* no registered handler, die on SIGABRT */
    signal (SIGABRT, SIG_DFL);
    kill (getpid(), SIGABRT);

    /* should not be needed */
    _exit(255);
}

(in particular you probably want things like the malloc/free/realloc as they fixed a bunch of bugs).

Thanks, I'll take a closer look. I see you're running a fixed-up version of the K&R allocator, nice. I also replaced ours with a very similar allocator from V7, since dev86 realloc definitely has problems. I don't think it has your fixes for signed sbrk though, which would be nice. ELKS is still limited to 32767 byte max allocations.

Some initial work was done but no 8086 port proper exists, just some stuff to sketch it out and compare compilers.

Perhaps I'll try building it, just for fun. Do you have any preferences on emulators instead of real hardware?

Have you seen Blink, the x86_64 long mode emulator with visual instruction tracing and reverse execution history? Its pretty cool. I recently took it and replaced the complex x86_64 virtual machine with a tiny 8086-only emulator and disassembler, and paired it with the cool Blink TUI, in Blink16. It works with an updated a.out symbol table format recently added to ELKS executables, and now will visually trace instruction execution symbolically for an ELKS cold boot all they way up to a shell prompt, as well as application mode emulation for a.out and DOS MZ executables. If there are some simple Z80/8080/6502 etc CPU emulators and disassemblers, it could be fairly straightforward to get such a thing working for Fuzix.

[EtchedPixels]

I've got a bunch of emulations I use - for a lot of them it's ones I put together - see the EmulatorKit repository. I have an 80C188 board I designed that I need to finish writing some firmware for so I can run ELKS or Fuzix on it.

[EtchedPixels]

On Sat, 25 Mar 2023 20:08:02 -0700 Gregory Haerr @.***> wrote:

The libc ought to port back to ELKS as that is where much of the basic libc came from

Yes, it looks like Fuzix libc is also from Alistair Riddoch's work and dev86 from long ago. We've done quite a bit of cleanup on it, and replaced or fixed a lot of routines. A quick look shows that your abort.c is still in trouble, unmodified from the original dev86 version, notice the arguments to kill are backwards (!):

void abort(void)
{
        signal(SIGABRT, SIG_DFL);
        kill(SIGABRT, getpid());        /* Correct one */
        pause();                        /* System may just schedule */
        signal(SIGKILL, SIG_DFL);
        kill(SIGKILL, getpid());        /* Can't trap this! */
        _exit(255);                     /* WHAT!! */
}

It also suffers from the problem of not calling the registered SIGABRT handler, if present. We replaced it with this:

#include <signal.h>
#include <stdlib.h>
#include <unistd.h>

void
abort(void)
{
    /* call registered handler if any, or die if none */
    kill (getpid(), SIGABRT);

    /* no registered handler, die on SIGABRT */
    signal (SIGABRT, SIG_DFL);
    kill (getpid(), SIGABRT);

    /* should not be needed */
    _exit(255);

Thansk - I did something similar - although I needed to unmask the signal. Also borrowed the mail app and added some security checks/fixes to it.

Will have a look at the basic too when I get some time.

[ghaerr]

I did something similar - although I needed to unmask the signal.

I notice that your updated abort.c still has one kill with the parameters reversed. (Also, its not possible to mask or catch SIGKILL, correct? Thus no need for signal(SIGKILL, SIG_DFL). )

Also borrowed the mail app and added some security checks/fixes to it.

mail was recently ported and contributed by @ccoffing, I haven't even had time to try it out yet. Perhaps he will be interested in your changes.

I just ported your cave/adventure to ELKS. Pretty cool, and nice port. Took all of a couple minutes to get it running :)

Will have a look at the basic too when I get some time.

I looked at quite a few basic's before selecting this one to port to ELKS. I really like this one because:

• Fast tokenized execution
• No allocations, all tokens and variables in fixed size array (tokens at low indices, variables at high indices).
• Strings, float and (some) fast integer support
• Easy to add new commands or functions
• Seperate host*.c files allow implementation of platform-specific features

[EtchedPixels]

what I get for doing it when rushing in the middle of another big change - fixed this time I think to match POSIX.

[ghaerr]

fixed this time I think to match POSIX.

Looks good! (And happens to match the version I wrote without consulting POSIX, luckily for me :)

Also, thanks for removing the generated .s files, I can now clone the repo successfully on macOS. I'll take a deeper look at all your good stuff and consider trying to build an 8086 version of FUZIX just for fun.