clang notes for a DEC C coder.
-
Topic author - Master
- Posts: 127
- Joined: Mon Aug 09, 2021 7:59 pm
- Reputation: 0
- Status: Offline
clang notes for a DEC C coder.
Here's some things I've learned doing an experimental build of my pet project using clang in place of the classic DECC compiler:
Clang doesn't use DCL parse, so all the qualifiers have to be converted to unix-style switches. There are good and bad aspects to this. It also doesn't apply a default file type to the input file. I ended up saving the output of "clang -help" to use as a reference.
The default pointer size is 64 bits. Not that much of a problem if you already accommodate /pointer_size=64.
The size of a clang long is 64 bits (the same size as a long long), a huge change from the DECC attitude that long equates to DEC's traditional 32-bit hardware longword. The RTL and system service documentation uses longword all over the place to describe arguments, so my code tended to use long rather than int as the data type for variables that were arguments to those functions. Long declarations have to be replaced with __int32.
The %x conversion specifier in printf format strings doesn't accept pointers and must be changed to %p.
Both compilers magically convert the argv data type in a main() function to an array of short pointers. I couldn't find a clang switch to do the equivalent of /pointer_size=long=argv.
Clang doesn't support the module pragma (#pragma module name ident-string).
Clang can digest the 260K line sqlite3.c amalgamation on X86 without excessive pagefile usage, unlike VSI C.
Clang doesn't use DCL parse, so all the qualifiers have to be converted to unix-style switches. There are good and bad aspects to this. It also doesn't apply a default file type to the input file. I ended up saving the output of "clang -help" to use as a reference.
The default pointer size is 64 bits. Not that much of a problem if you already accommodate /pointer_size=64.
The size of a clang long is 64 bits (the same size as a long long), a huge change from the DECC attitude that long equates to DEC's traditional 32-bit hardware longword. The RTL and system service documentation uses longword all over the place to describe arguments, so my code tended to use long rather than int as the data type for variables that were arguments to those functions. Long declarations have to be replaced with __int32.
The %x conversion specifier in printf format strings doesn't accept pointers and must be changed to %p.
Both compilers magically convert the argv data type in a main() function to an array of short pointers. I couldn't find a clang switch to do the equivalent of /pointer_size=long=argv.
Clang doesn't support the module pragma (#pragma module name ident-string).
Clang can digest the 260K line sqlite3.c amalgamation on X86 without excessive pagefile usage, unlike VSI C.
Re: clang notes for a DEC C coder.
-pointer-size=argv64 does the trick
You can always find out the equivalent of the qualifiers and clang options using CXX/verb. i.e.
CXX/verb/pointer_size=long=argv. test.c
(if test.c exists) gives you the options.
Jouk
Re: clang notes for a DEC C coder.
Thanks for the notes/feedback.
Yes, the move to sizeof(long)==64 is a big change as is the default changes for pointer-size, name upcasing, etc. The long change impacted lots of our code as well from system headers to DECwindows.
You'll still find that using scanf to a 64-bit long only fills in the bottom 32-bits as the CRTL still believes that long is just 64-bits. You have to change the format modifier. We're still thinking about how to deal with this.
Is the pragma module important to you and others? We can add that if desired.
As for the memory usage of VSI C vs clang, that would have to be either in the frontend or in the G2L converter. For certainly large structured constants, G2L can be a pig when creating LLVM constant objects. Perhaps we need to use that sqlite3 example and do some analysis?
Yes, the move to sizeof(long)==64 is a big change as is the default changes for pointer-size, name upcasing, etc. The long change impacted lots of our code as well from system headers to DECwindows.
You'll still find that using scanf to a 64-bit long only fills in the bottom 32-bits as the CRTL still believes that long is just 64-bits. You have to change the format modifier. We're still thinking about how to deal with this.
Is the pragma module important to you and others? We can add that if desired.
As for the memory usage of VSI C vs clang, that would have to be either in the frontend or in the G2L converter. For certainly large structured constants, G2L can be a pig when creating LLVM constant objects. Perhaps we need to use that sqlite3 example and do some analysis?
-
Topic author - Master
- Posts: 127
- Joined: Mon Aug 09, 2021 7:59 pm
- Reputation: 0
- Status: Offline
Re: clang notes for a DEC C coder.
The use case for pragma module is when using it with object libraries. Sometimes you want a library/list to show a different module name than its source file name and the ident string (/list/full) can show the release version.jreagan wrote: ↑Tue Jan 07, 2025 3:34 pmIs the pragma module important to you and others? We can add that if desired.
As for the memory usage of VSI C vs clang, that would have to be either in the frontend or in the G2L converter. For certainly large structured constants, G2L can be a pig when creating LLVM constant objects. Perhaps we need to use that sqlite3 example and do some analysis?
The current VSI C for X86 appears somewhat better behaved than the original release, requiring maybe 20-50% more pgflquo (~900K) than when using clang (with significantly more CPU). If you give it insufficient memory, it behaves erratically. It can abort, or take twice as long, or just sit and spin indefinitely. I'll try to make a condensed build environment you can play with to compare VSIC/clang.
Re: clang notes for a DEC C coder.
All of the native compilers were originally built with non-optimizing cross-compilers. Since then, we now use the native compilers to build the native compilers. However, some of those still used /NOOPT in the build scripts. I think we have all of them building native with default optimizations by now.
-
Topic author - Master
- Posts: 127
- Joined: Mon Aug 09, 2021 7:59 pm
- Reputation: 0
- Status: Offline
Re: clang notes for a DEC C coder.
I packaged the large source file with a couple command procedures in a zip archive, compile_sqlite.zip and placed it on my google drive. I made a procedure to get accounting info to compare the different compilers when run with different page file limits.
Code: Select all
$ @detached_compile "clang" 7000000
%RUN-S-PROC_ID, identification of created process is 0000019B
started detached process 'DC_clang' with pgflquo of 7000000...
Output file DC_clang_detached.log, finished 9-JAN-2025 07:16:29.68
$! +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
$ clang -o sqlite3_clang.obj -show-source -show-header -pointer-size=long -include []platform.h sqlite3-vms.c
Object sqlite3_clang.obj has size 5167
JONESD job terminated at 9-JAN-2025 07:16:29.11
Accounting information:
Buffered I/O count: 880 Peak working set size: 652320
Direct I/O count: 1120 Peak virtual size: 1032720
Page faults: 39714 Mounted volumes: 0
Charged CPU time: 0 00:00:06.21 Elapsed time: 0 00:00:06.65
Code: Select all
$ @detached_compile "cc" 7000000
%RUN-S-PROC_ID, identification of created process is 0000019F
started detached process 'DC_cc' with pgflquo of 7000000...
Output file DC_cc_detached.log, finished 9-JAN-2025 07:17:25.98
$! +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
$ cc sqlite3-vms.c /float=ieee/first_include=[]platform.h -
/optimize=(tune=host)/architecture=HOST/L_DOUBLE=64 -
/nest=primary /object=sqlite3_vsic.obj
Object sqlite3_vsic.obj has size 5019
JONESD job terminated at 9-JAN-2025 07:17:25.02
Accounting information:
Buffered I/O count: 759 Peak working set size: 990528
Direct I/O count: 1161 Peak virtual size: 1372416
Page faults: 102366 Mounted volumes: 0
Charged CPU time: 0 00:00:28.96 Elapsed time: 0 00:00:29.93
Code: Select all
$ @detached_compile "cc"
%RUN-S-PROC_ID, identification of created process is 000001A1
started detached process 'DC_cc' with pgflquo of 512000...
Output file DC_cc_detached.log, finished 9-JAN-2025 07:21:51.60
$! +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
$ cc sqlite3-vms.c /float=ieee/first_include=[]platform.h -
/optimize=(tune=host)/architecture=HOST/L_DOUBLE=64 -
/nest=primary /object=sqlite3_vsic.obj
%DEBUGBOOT-W-EXPGFLQUOTA, exceeded pagefile quota
%NONAME-F-NOMSG, Message number 05F78414
$ compile_done:
Object sqlite3_vsic.obj not produced!
$ sv = 0
$!
$ exit
$ exit
JONESD job terminated at 9-JAN-2025 07:21:50.93
Accounting information:
Buffered I/O count: 555 Peak working set size: 463696
Direct I/O count: 998 Peak virtual size: 824928
Page faults: 58362 Mounted volumes: 0
Charged CPU time: 0 00:00:05.40 Elapsed time: 0 00:00:05.51
If you try to elide clang's 64-bit pointer issue by compiling with -pointer-size=short, this bizaare thing happens:
Code: Select all
$ clang mcopy.c -pointer-size=short
mcopy.c:12:24: error: too many arguments to function call, expected 2, have 3
memcpy ( dst, src, len );
^~~
1 error generated.
Last edited by jonesd on Thu Jan 09, 2025 9:24 am, edited 4 times in total.
Re: clang notes for a DEC C coder.
Using foreign-mechanism clang to compile c code is still a work-in-progress. There are places in our headers that check for __clang but also need to check for __cplusplus (but do not). I can easily imagine getting confusing behaviors or errors.
-
Topic author - Master
- Posts: 127
- Joined: Mon Aug 09, 2021 7:59 pm
- Reputation: 0
- Status: Offline
Re: clang notes for a DEC C coder.
I have a UWSS written in C whose source is embedded in a command procedure to help ensure the special incantations to build it into a protected image are used. The normal C compilers have no trouble with specifying the input as sys$input+sys$library:sys$lib_c.tlb/library, followed by a "$ DECK" DCL command, the C source, and a "$ EOD". The equivalent for clang, is "-x c - -text-library=sys$library:sys$lib_c.tlb".
Last edited by jonesd on Fri Jan 17, 2025 10:07 pm, edited 1 time in total.