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 (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 (https://github.com/danielgaskell/scc/blob/main/doc/index.md), 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 (https://symbos.org/quigs.htm), 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!)
Awesome work !!! , congratulations :o :o :o
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.
In what RAM configuration is the screen drawn? C7+n*8? In which 16kB bank is the drawing routine located?
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) ;)
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".
Awesome! I have to play with this one day, I actually like this awful language C :)
Quote from: Benedikt on 19:43, 23 September 24They 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). :P But in practice you are probably correct. In the meantime, of course, one can change this with a #define.
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?
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!
Something wrong. ::)
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.
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:
scc1-compiler1.jpg
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:
scc2-compiler2.jpg
Now the assembler is working, it is using the full CPU power, looks good!
scc3-assembler.jpg
And finally the linker:
scc4-linker.jpg
Reloc runs so fast, that it was already finished, when I made the next photo:
scc5-reloc.jpg
Finished after 20 minutes. Now let's test the compiled EXE file:
scc6-done.jpg
Yes, it works great! 8) Congratulation, SCC just looks, feels and works so cool!
Now I need McArti0s new TurboCPC ;D
Quote from: Prodatron on 10:34, 25 September 24Now I need McArti0s new TurboCPC ;D
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.
Very nice! :D
(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?)
Quote from: prevtenet on 16:53, 25 September 24dragging 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. :laugh:
Shift+F4 on WinAPE too.
the war continues >:(
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.
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.
Maybe you need to add some kind of artificial header information (storing the exact file length) in front of the file before compiling?
Quote from: prevtenet on 19:55, 25 September 24AMSDOS 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?
Quote from: prevtenet on 19:55, 25 September 24I am not sure if there is an easy solution to this
In Windows
2restoreFilesLength.bat
cd %0
dir /s >Fileslen.trmand created FilesLen.trm
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 freeIn SymbOS the code uses FilesLen.trm to trim all files. 8)
Quote from: McArti0 on 19:37, 26 September 24Quote from: prevtenet on 19:55, 25 September 24AMSDOS 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.
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) (https://github.com/EtchedPixels/FUZIX/tree/master/Applications)
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.
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.
First, thanks again, this is great tool !!!
Now, I would like to try to port some of my C code used with sdcc compiler where I used inline asm.
I understood that there is no support for inline asm but that linking with .asm (or .s) should work.
Can someone write me the smallest possible example where I would have a function with 2 variables (each 2 bytes) written in assembler - which could be called from a C program as a C function?
(previously this was easy with inline asm and some push/pop for arguments)
btw, what is asm syntax used in scc?
The documentation on mixing asm/C is here (https://github.com/danielgaskell/scc/blob/main/doc/special.md#interfacing-with-assembly-code); I think this probably has most of the examples you need.
The only difference with a two-parameter routine is that there will be two 16-bit values on the stack on entry to the routine instead of one, with the first parameter being on the top of the stack (after the return address, of course). The example gets these parameters with POP, but another good approach (that doesn't require cleaning up the stack afterwards) is set IX to the initial stack pointer, like:
.export _asmfunc
_asmfunc:
ld ix,#0x00
add ix,sp
ld l,(ix+2) ; HL = first parameter
ld h,(ix+3)
ld e,(ix+4) ; DE = second parameter
ld d,(ix+5)
; do something with HL, DE...
ret
As you can see one major syntax difference from SDCC is using the (ix+2) format for index registers rather than 2(ix). SDCC's syntax is kind of weird, the syntax used by SCC is more standard (it seems pretty close to the Maxam-style syntax used by WinApe, without some of the more advanced features).
SCC v1.1 has been published on GitHub (link (https://github.com/danielgaskell/scc/releases/tag/v1.1)). Despite the small increment in version number, this is a major feature release focused on multimedia and compatibility with the forthcoming SymbOS 4.0.
Major new features:
- A graphics library for game development, including a tool for converting images to graphics assets.
- Cross-platform music and sound support (SymbOS 4.0+ only).
- The floating-point library has been fixed (and now runs 2-5x faster than SDCC).
- SymbOS .HLP files of the documentation.
- Various other tweaks and bugfixes (register variables now work, faster core routines, etc.)
Check out the new graphics library in the new PDP-8 Emulator (https://symbos.org/appinfo.htm?00063) for SymbOS! (Although, that source code might not be the best example of how to use it in practice...)