SymbOS C Compiler (v1.0 released)

[prevtenet]

I am pleased to present the SymbOS C Compiler (SCC), a fork of Alan Cox's brilliant Fuzix Compiler Kit reworked into a complete development toolchain for SymbOS. Currently SCC runs on Windows and cross-compiles binaries for SymbOS, but can also cross-compile itself to run natively (albeit slowly) on SymbOS itself. (Yes! A full C compiler running natively on SymbOS!)

Get it here: https://github.com/danielgaskell/scc/releases

Features:

• Full ANSI C compiler and toolchain (preprocessor, assembler, linker, etc.)
• Native libc and stdio ports - many existing (small) console programs can be recompiled into SymShell apps with little or no modification.
• Extensive wrappers and utility functions for SymbOS system calls.
• Over 25,000 words of documentation, including a quickstart guide to teach you the basics of SymbOS development, a comprehensive system call reference, and a complete example GUI app for reference (programmer's calculator).
• Multithreading (yes, really!)
• Support for mixing C and assembly source files.

Limitations:

• Floating-point support is currently flaky (and scheduled for a complete rewrite).
• Many libc functions remain under-tested, although the library is stable enough for the compiler to be self-hosting.

System requirements:

• Windows 98 or newer (desktop version) - a Linux port should also be straightforward if anyone wants it.
• SymbOS 3.1 or newer, with 256 KB RAM and a FAT filesystem (native version).

Planned future work: graphics libraries (and associated support utilities) for game development.

SCC is considered stable, but is still under active development, so feel free to contact me with bug reports or coding questions. A major goal of this project is to make it easier for people to get into SymbOS development, so I'm always happy to help out!

(In the same spirit of encouraging development, I'll also shout out Trebmint's Quigs IDE, which offers a more point-and-click, Visual Basic-like experience for SymbOS GUI development. SCC implements a more industry-standard, well-documented language with complete low-level control over the system, but Quigs automates various things you have to do manually in C. So, pick the best tool for your needs - I use both!)

[XeNoMoRPH]

Awesome work !!! , congratulations

[Prodatron]

What a giant project! For me this is a dream!

Beside the fact, that
- you can compile the compiler by itself in SymbOS
- porting existing UNIX tools to SymbOS/SymShell

- and of course having a fantastic C developer tool for SymbOS
 
...the documentation is so great, it's a pleasure to read it!
https://github.com/danielgaskell/scc/blob/main/doc/symbos.md
https://github.com/danielgaskell/scc/blob/main/doc/syscalls.md
https://github.com/danielgaskell/scc/blob/main/doc/special.md

Tomorrow I will have more time for testing and experimenting. I should make a video as well with a real machine.

[McArti0]

In what RAM configuration is the screen drawn? C7+n*8? In which 16kB bank is the drawing routine located?

[Prodatron]

In #C0 or #C4-#C7 mode. The low level screen driver is placed in bank0, block 2 (somewhere between #8000-#bfff).
But this has nothing to do with SCC (SymbOS C Compiler)

[Benedikt]

This appears to be a nice little compiler, over all. Most importantly little.
What I, personally, find a bit icky about the additional keywords _data and _transfer is that they start with a single underscore.
Identifiers starting with a single underscore are technically reserved for the library, whereas identifiers reserved for the implementation, i.e. the compiler, should start with a double underscore.
I therefore recommend to rename the keywords accordingly. The few programs that already rely on these keywords could then either be adapted or use appropriate wrapper macros.

EDIT

Looked it up: They are actually defined as "reserved for use as identifiers with file scope" (_) and "reserved for any use" (__), respectively, in paragraph 7 of Chapter 6.4.2.1 (Language / Lexical elements / Identifiers / General) of the latest publicly available draft of ISO/IEC 9899:2023 "Programming languages - C".

[BSC]

Awesome! I have to play with this one day, I actually like this awful language C

[prevtenet]

They are actually defined as "reserved for use as identifiers with file scope" (_) and "reserved for any use" (__), respectively

Well, if we want to be pedantic, this is an extended keyword, not an identifier, and SCC doesn't claim C23 compliance anyway (it's closer to C89, which does not make this distinction in exactly the same way). But in practice you are probably correct. In the meantime, of course, one can change this with a #define.

[McArti0]

I barely got it onto a 1.2MB bootable floppy disk but I can't compile it because there's not enough space 
How to make samples and compilation take place on a different disk?

[prevtenet]

Hmm, some things you might try:

- Delete libm.a, copt.exe, and rules.z80, as these are not used by default on the native version (only with special compile options).
- Delete any header files you aren't using.
- Temporary files are written to the current SymShell folder, so if you have dual drives, you can start in the source's folder and invoke cc using the absolute path to the other drive.
- Try compiling something smaller.
- Run the compiler stages separately. Use cc with -V to see what commands are being run; if the .exe files are renamed to .com they can be run as separate SymShell commands, swapping out anything that isn't needed for that stage to make space. (Only cpp needs the header files, and only ld needs the .a and .o files - the rest of the executables work directly with the source/swap files.)

Note also that compilation may not finish correctly on non-FAT-formatted drives, for reasons discussed in the documentation. The native version is really intended for mass storage devices, but if you can get it running on a floppy, that would be cool!

[McArti0]

Something wrong. 

[prevtenet]

Oh, I just noticed that yesterday. When compiling natively non-default optimization options (like -Os, optimize for size) can run out of memory. If you remove the -Os option from makecalc.bat it should compile fine.

The issue is copt, which is a peephole optimizer. This generally isn't run on native builds because it's slow and only mildly useful. Apps have to jump through some extra hoops to use >64k of memory in a single SymbOS process, which copt isn't currently designed to do, so it can run out of memory even if there appears to be banked memory available.

[Prodatron]

Thanks for the hint, I had this issue as well, it's fine now!

I just made a test on my real 4MHz CPC. It is very interesting to see the CPU usage!

Compiler "cc1" runs shortly after the start of the entire process:
You cannot view this attachment.

Compiler "cc2" is running. It seems that the system loses some CPU time to the idle process due to the messaging system. I guess I need to optimize this in the future:
You cannot view this attachment.

Now the assembler is working, it is using the full CPU power, looks good!
You cannot view this attachment.

And finally the linker:
You cannot view this attachment.

Reloc runs so fast, that it was already finished, when I made the next photo:
You cannot view this attachment.

Finished after 20 minutes. Now let's test the compiled EXE file:
You cannot view this attachment.

Yes, it works great!  Congratulation, SCC just looks, feels and works so cool!

Now I need McArti0s new TurboCPC

[McArti0]

Now I need McArti0s new TurboCPC

The best thing is that for external RAM it will be quite easy to achieve 16-20MHz. Like Amiga fast and slow RAM. I am also thinking about PAL which in C2 would additionally show 8 x 16k parts bank 0,1 from C000.

[prevtenet]

Very nice!

(This is probably a good point to mention that, for actual development, cross-compiling on a PC and dragging the resulting executable into the WinApe disk editor for testing takes about 2 seconds rather than 20 minutes. But where's the fun in that?)

[McArti0]

dragging the resulting executable into the WinApe disk editor for testing takes about 2 seconds

This is not Retro. You'll be burned at the stake soon. 

Shift+F4 on WinAPE too.

[McArti0]

the war continues 

[prevtenet]

So, this is what happens when SCC is run on a non-FAT filesystem (or when the .o object files or .a library files are corrupted by being passed through a non-FAT filesystem).

The problem is that the AMSDOS and CP/M filesystems store files in 128-byte blocks rather than recording the actual binary length of the file; instead they record the end of the file with a "soft EOF" (character 0x1A) followed by some garbage to pad out the rest of the 128-byte block. For the build stages that handle text files, this isn't a problem, because they can identify the EOF, but library files are binary and may use 0x1A for meaningful data. So saving the library files to an AMSDOS or CP/M disk, even temporarily, will corrupt them.

I am not sure if there is an easy solution to this (beyond the current underwhelming "don't do that, then"). Possibly LD could be reconfigured to assume EOF and throw a warning when it encounters garbage instead of erroring out, but I'm not sure this would actually work because there's still the problem of knowing where the file actually ends. Possibly also the file length could be recorded internally, but this would require breaking and fixing several parts of the existing build chain.

[Prodatron]

Please keep the existing way.
There is no reason for breaking well-established things just to support a filesystem from the 1970ies, as it runs in SymbOS anyway.

[HAL6128]

Maybe you need to add some kind of artificial header information (storing the exact file length) in front of the file before compiling?

[McArti0]

AMSDOS or CP/M disk, even temporarily, will corrupt them.

I copied from DATA AMSDOS to FAT12.

The only idea I have on how to put files into DSK is to put it on edit disk AMSDOS in WinAPE.

I already thought it was a problem with my long track 15sec per tr.

But why sometimes the same disc work?

[McArti0]

I am not sure if there is an easy solution to this

In Windows

2restoreFilesLength.bat

Code Select Expand

cd %0
dir /s >Fileslen.trm
and created FilesLen.trm

Code Select Expand

Volume in drive C is Windows
 Volume Serial Number is -

 Directory of C:\scc_symbos_v1.0

26.09.2024  22:11    <DIR>          .
26.09.2024  22:11    <DIR>          ..
26.09.2024  21:57                29 2restoreFilesLength.bat
21.09.2024  22:50            51˙718 as.exe
21.09.2024  22:50            33˙940 cc.com
21.09.2024  22:50            42˙046 cc0.exe
21.09.2024  22:50            68˙107 cc1.exe
21.09.2024  22:50            70˙315 cc2.exe
21.09.2024  22:50            31˙171 copt.exe
21.09.2024  22:50            26˙367 cpp.exe
26.09.2024  22:11                 0 Fileslen.trm
21.09.2024  22:45             2˙511 install.txt
21.09.2024  22:50            46˙883 ld.exe
26.09.2024  22:11    <DIR>          lib
21.09.2024  22:50            16˙738 reloc.exe
06.09.2024  09:46             5˙101 rules.z80
26.09.2024  22:11    <DIR>          sample
              13 File(s)        394˙926 bytes

 Directory of C:\scc_symbos_v1.0\lib

26.09.2024  22:11    <DIR>          .
26.09.2024  22:11    <DIR>          ..
17.09.2024  10:12             2˙966 crt0.o
26.09.2024  22:11    <DIR>          include
19.09.2024  08:43           154˙654 libc.a
17.09.2024  08:33           197˙894 libm.a
22.09.2024  23:17            35˙791 libma.zip
07.09.2024  23:38            24˙358 libsym.a
30.08.2024  12:17            93˙558 libz80.a
               6 File(s)        509˙221 bytes

 Directory of C:\scc_symbos_v1.0\lib\include

26.09.2024  22:11    <DIR>          .
26.09.2024  22:11    <DIR>          ..
19.09.2024  09:24               641 assert.h
24.08.2024  05:27               679 ctype.h
24.08.2024  05:27             3˙901 errno.h
24.08.2024  05:27             1˙070 fcntl.h
19.09.2024  09:28                82 features.h
24.08.2024  05:27               763 float.h
24.08.2024  05:27               280 getopt.h
06.09.2024  09:46                24 iobuf.h
24.08.2024  05:27               936 limits.h
24.08.2024  05:27             1˙556 locale.h
24.08.2024  05:27               261 malloc.h
24.08.2024  05:27             5˙363 math.h
24.08.2024  05:27                49 memory.h
24.08.2024  05:27               747 regexp.h
06.09.2024  09:46               270 setjmp.h
19.09.2024  09:29               534 stdarg.h
24.08.2024  05:27               116 stdbool.h
19.09.2024  09:29               149 stddef.h
24.08.2024  05:27             1˙106 stdint.h
19.09.2024  09:31             5˙238 stdio.h
25.08.2024  05:00             3˙581 stdlib.h
03.09.2024  07:22             2˙892 string.h
26.09.2024  22:11    <DIR>          symbos
10.09.2024  09:57               457 symbos.h
26.09.2024  22:11    <DIR>          sys
11.09.2024  09:31             6˙038 syscalls.h
19.09.2024  09:32             1˙887 time.h
24.08.2024  05:27               150 types.h
06.09.2024  09:46             4˙025 unistd.h
24.08.2024  05:27               282 utime.h
19.09.2024  09:32               284 varargs.h
24.08.2024  05:27                23 wait.h
              30 File(s)         43˙384 bytes

 Directory of C:\scc_symbos_v1.0\lib\include\symbos

26.09.2024  22:11    <DIR>          .
26.09.2024  22:11    <DIR>          ..
10.09.2024  10:09               389 clip.h
10.09.2024  09:12             1˙107 core.h
10.09.2024  10:09             1˙449 device.h
10.09.2024  10:09             3˙256 file.h
10.09.2024  10:09               578 header.h
10.09.2024  10:21             2˙960 keys.h
10.09.2024  10:10             1˙285 memory.h
10.09.2024  10:02             3˙110 msgid.h
10.09.2024  10:10             2˙265 network.h
10.09.2024  10:10             1˙565 popups.h
10.09.2024  10:10             1˙286 proc.h
10.09.2024  10:10             1˙017 shell.h
10.09.2024  10:10               240 systray.h
10.09.2024  10:10               228 threads.h
10.09.2024  10:10               500 time.h
11.09.2024  06:25            10˙596 windows.h
              16 File(s)         31˙831 bytes

 Directory of C:\scc_symbos_v1.0\lib\include\sys

26.09.2024  22:11    <DIR>          .
26.09.2024  22:11    <DIR>          ..
24.08.2024  05:27               361 cdefs.h
24.08.2024  05:27                18 errno.h
24.08.2024  05:27                52 exec.h
24.08.2024  05:27               101 fp.h
24.08.2024  05:27               590 library.h
24.08.2024  05:27               347 param.h
24.08.2024  05:27               498 rtc.h
24.08.2024  05:27               310 seek.h
24.08.2024  05:27             1˙791 stat.h
24.08.2024  05:27             1˙645 time.h
24.08.2024  05:27               293 times.h
17.09.2024  08:33             1˙706 types.h
24.08.2024  05:27             1˙716 wait.h
              13 File(s)          9˙428 bytes

 Directory of C:\scc_symbos_v1.0\sample

26.09.2024  22:11    <DIR>          .
26.09.2024  22:11    <DIR>          ..
08.09.2024  10:11            14˙182 basic.c
30.08.2024  08:25               147 calc.sgx
10.08.2024  08:47               298 calc16.sgx
21.09.2024  22:32                51 makebas.bat
21.09.2024  22:32                82 makecalc.bat
19.09.2024  10:52            21˙311 progcalc.c
07.09.2024  23:52             1˙687 threads.c
10.09.2024  10:13             1˙919 windemo.c
               8 File(s)         39˙677 bytes

     Total Files Listed:
              86 File(s)      1˙028˙467 bytes
              17 Dir(s)  67˙438˙002˙176 bytes free
In SymbOS the code uses FilesLen.trm to trim all files.

[prevtenet]

AMSDOS or CP/M disk, even temporarily, will corrupt them.

I copied from DATA AMSDOS to FAT12.

The only idea I have on how to put files into DSK is to put it on edit disk AMSDOS in WinAPE.

The suggestion in the documentation is to ZIP the files and then use the SymbOS "unzip" utility to extract them once they're on the FAT disk. (I am not sure if all types of ZIP files are supported, and I don't think the SymbOS unzip supports subdirectories, but zipping the library files with 7zip and copying them to an emulated FAT partition via a 180k AMSDOS floppy image worked for me.)

Interesting that it sometimes works in your disk, though. It might depend on exactly what garbage gets added to pad the file to a multiple of 128 bytes.

[ajcasado]

Great work!

I couldn't help trying to compile applications from the fuzix repository to try this.

FUZIX/Applications at master · EtchedPixels/FUZIX (github.com)

I started from a simple one, cowsay. It compiled unchanged without any complain and worked perfectly on Symbos. Very cool.

Next step (and last for today) has been startrek:

• It throws an error at the linking phase: startrek.o: Unknown symbol '_chdir'. commenting the line 292 solves the problem if you run the com executable in the same path as the files startrek.fatal, startrek.intro, startrek.logo and startrek.doc. Also this files with more than 3 chars in te filename extension must be renamed to only three chars extensions and change the code in startrek.c to use the corrected filenames. I guess that this function is not implemented in the library.
• Second problem is that the game stops at the input response to the question for showing the documentation. This problem is solved changing the function input(char *b, uint8_t l). When you hit enter after answering y or n the cursor do a CR without LF. I solved this issue changing '\n' for 13 in the line 220 (while((c = getchar()) != 13) {). I guess that this is an unexpected behavior of symshell for a compiler that is oriented to an unix like enviroment.
• Third problem, is that the variables declared as register don't behave well if used as loop indexes (at least in for loops). The commands srs and lrs only represent one line of the sector and quadrant map in the game, the inner for loop is not executed in the printing algorithm of the functions short_range_scan() and long_range_scan(). The command dam only shows a system of the enterprise. I changed all the the affected declarations of for loop indexes to uint_8t from register int. I tried to catch the fail in the compilation debugging the assembly in startrek.s but my assembly skill level is not very good.

Attached is a dsk image with the compiled programs, the modified source of startrek and the untouched one of cowsay. I didn't tested startrek.com exhaustively, but i guess that is mostly playable.

Thanks @prevtenet for this compiler, now there is a lot of potentially portable code to the cpc with little effort thanks to your development.

[prevtenet]

Nice!

I believe the issue with register variables is that system calls (including console output) do not always preserve registers correctly - this is on my list to look into, along with the best way to fake the behavior of chdir, since SymbOS doesn't actually track the working directory in quite the way most apps expect.

SymShell does typically return character 13 (\r) instead of character 10 (\n) for "enter". Ideally input() ought to convert this automatically, but evidently it doesn't, so I'll look into this.