On Saturday, June 26, 2021 at 7:58:13 AM UTC-4,
[email protected] wrote:
суббота, 26 июня 2021 г. в 01:34:38 UTC+3, [email protected]:
On Wednesday, March 31, 2021 at 4:38:57 PM UTC-4, [email protected] wrote:
среда, 31 марта 2021 г. в 20:31:59 UTC+3, Андрей Никитин:
среда, 31 марта 2021 г. в 19:30:24 UTC+3, [email protected]:
On Sunday, March 28, 2021 at 6:51:15 PM UTC-4, [email protected] wrote:
Today on github.com I posted the decompiled code
CPP.COM programs from the Hi-Tech C compiler v3.09 for CP/M and a new preprocessor for this compiler with support for C++ comments and compatible with the former. The code can be downloaded from the following link
https://github.com/nikitinprior/dcpp
Very Welcome Change!
Thanks for your work! Much appreciated. Less changes to C code to bring to Z80. As a PS. The new CPP cannot
be built on a "real box" -- it needs more than 63k CP/M (I guess zxc provides 64k environment, or maybe even
larger). Not a serious issue....
Thanks Again!
FredW
Thank you for your kind wishes.
I compiled the new preprocessor using zxc. At first I tried to leave all the functions that were present in the file with the source code of the J. Schilling program. However, I ran into a lack of memory while optimizing the program. The next
step was to remove some additional features that were missing in the Hi-Tech C version. That helped. The programs compiled normally. Perhaps part of the code needs to be moved into a separate function and the remaining little-demanded features should be
removed.
In addition to handling C++ comments, it is important to be able to compile the program on real hardware. This is one of my tasks.
Regards
Andrey Nikitin
I installed a new preprocessor on my computer in the Hi-Tech C environment and in the process I will check the correctness of its work. I would be grateful to everyone who can help with testing and finding bugs. Together w can bring it to a good
sta
Andrey
Hope you get this -- I have been using HI-TECH C 3.09 with your new CPP. So far, everything is great!
But note the following:
1 - #pragma, #error, #ident are... useless. just copied through. Can these be discarded? Or, just let them be
bad preproc directives (saves space). HI-TECH z80 implements NO pragmas.
2 - It would be VERY useful to have "#warning message" -- just display file: line: warning: message on the console
and continue. Do NOT copy through to output!
This would allow better compatibility with gcc. Right now, we can get a warning from GCC but NOT hi-tech
#ifdef z80
... something
#else
#pragma GCC warning "gcc not good here"
#endif
does it. But... we cannot warn on z80 compile for anything... #pragma is copied through, and will
cause an error in P1 We cannot use #warning, as that will cause CPP to fail. And that is why I
would love to have #warning on the HI-TECH CPP. #error COULD be coded to exit(1) the preprocessor.
That would be useful.
FredW
First you write:
"#pragma, #error, #ident are... Can these be discarded?",
and at the end you offer:
"#error COULD be coded to exit(1) the preprocessor."
this is not entirely logical.
I am not the author of this program, but only adapted it for compiling HI-TECH C 3.09.
The code for processing the "#error message " directive was already present in the program and it only needs to be activated. I have made the appropriate changes to the program and I express my gratitude for the comment made.
As for other directives, they do not interfere and do not require a lot of memory.
The "#warning message " directive can be added, but in GCC it is implemented via #pragma. Therefore, compatibility with GCC will not be achieved.
Thank you for your comments
Andrey Nikitin
Andrey -- The "#warning message" is actually supported by GCC. GCC produces
tuck:63:2: warning: #warning warning [-Wcpp]
If the "#warning# is inside a "#if 0 ... #endif", gcc ignores it -- BUT -- CPP.COM says:
tuck: 61: undefined control
AND STOPS THE COMPILATION. For a CPP directive inside of a block that is not being passed to P1 even! However, if the
"#warning message" is changed to #pragma GCC warn "message"
-- then GCC takes is as #warning and CPP.COM is ok with it because CPP.COM currently just passes the pragma along to P1.COM
As long as the pragma is inside a #if 0 then CPP.COM DOESN'T pass it on (GCC only code) and the warning is given.
Since GCC *also* implements #warning -- if CPP.COM implemented #warning we could have warnings inside GCC only blocks
and z80 only blocks.
Yes, I know you are not the orginal author -- I can make these changes on a fork. But I am hot and heavy in am9511
and won't get to it until.. after am9511. If #warning is NOT implemented, #pragma is neded for my use cases. Everything
is actually ok for me now that I have figured out the "#pragma GCC warn" work-around to the missing #warning.
And, thanks a whole bunch for the new CPP.COM ! This makes things easier. aAs an aside: If Iyou want to see a real HI-TECH C 3.09
problem: try
long = (unsigned char);
long = (long << 8) | (unsigned char);
long = (long << 8) | (unsigned char);
long = (long << 8) | (unsigned char);
That actually generates BAD C
ODE
!
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)