Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Paul Edwards" <mutazilah@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: 80386 C compiler
Date: Wed, 27 Nov 2024 13:23:49 +0800
Organization: A noiseless patient Spider
Lines: 128
Message-ID: <vi6adc$3shu6$1@dont-email.me>
References: <vhvbhf$28opb$1@dont-email.me> <vhvsm9$2bmq9$1@dont-email.me><vi0dt1$2el7m$1@dont-email.me> <20241125101701.894@kylheku.com><qrp9kjd09n2v3srmabqccmnsbr1r6nkm2m@4ax.com><20241125132021.212@kylheku.com><875xo9ln93.fsf@nosuchdomain.example.com><vi5elj$3kdmr$1@dont-email.me> <871pyxljfc.fsf@nosuchdomain.example.com>
Injection-Date: Wed, 27 Nov 2024 06:23:57 +0100 (CET)
Injection-Info: dont-email.me; posting-host="ff511d84c8d989f9586aca77125b5af3";
	logging-data="4081606"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18BCyNS2PaAIDxvKVT3u5DgUQYNzzMmy78="
Cancel-Lock: sha1:7aU2zLuwesE0WQTOGnBuCnXGKgE=
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Bytes: 5855

"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message
news:871pyxljfc.fsf@nosuchdomain.example.com...

> "Paul Edwards" <mutazilah@gmail.com> writes:
> > "Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message
> > news:875xo9ln93.fsf@nosuchdomain.example.com...
> >
> >> True, but I don't know of anyone who's interested in a C 90 compiler
> >> with this kind of extension.  Paul Edwards has made it clear he's only
> >> interested in unextended C90, and anyone else can just use a more
modern
> >> compiler.
> >
> > While not a "compiler" per se, there is one extension to
> > C90 I might add, which is to have formal names like:
> >
> > ESC_CHAR '\x1b'
> > ESC_CHAR_STR "\x1b"
> >
> > that would allow me to support ASCII and EBCDIC in
> > my "starter suite".
>
> I don't see why this needs to be a language extension.  Just define it
> as a macro wherever it's needed.

Because it is something I expect from the language - a portable
way to provide the keys required to drive an ANSI X3.64 terminal.

> > Microemacs and msged need them.
>
> Do they?

How else do you propose providing a fullscreen interface?

We have a standard - ANSI X3.64.

> > I probably need names for the control keys too for microemacs.
> >
> > I'll need to revisit the code to be sure.
>
> My guess is that getting microemacs and/or msged to work with EBCDIC is
> going to involve more than just defining the Escape character.

microemacs has been working on EBCDIC for years. I ported
it already (to a sufficient extent, anyway).

> For example, here's a code fragment from msged :
>
>     while ((ch != 'a') && (ch != 'r')) {
>         ch = 0x7f & getkey();
>         ch = tolower(ch);
>         if (ch == 0x1b)
>             return(NULL);
>     }

I haven't attempted to do msged yet. But yes, that's exactly
the sort of code that I want to eliminate. Although that
particular bit of code isn't in the msged version I am using:

D:\devel\msged\src>grep -i 7f *
fido.c:     tms.tm_year = (x & 0x7f) + 80;
keys.h: #define Key_C_BS   0x007f
keys.h: #define Key_A_8    0x7f00
spawn.asm: xfcb2           db      16 dup(?)       ; 70..7F - default FCB

D:\devel\msged\src>

I can't remember if I previously eliminated it myself, but if I did,
it must have been in the 1990s, because I see no change involving
a 7f from my oldest available release from the 1990s.

But yes - that's the whole point - I expect to be able to write
that code portably, in either the standard, or a modified
standard - whatever is required to get ANSI X3.159-1989
to support ANSI X3.64.

It could be an ANSI X3.64 extension I suppose.

> 0x1b is the ASCII code for the Escape character.  Defining a macro
> *within the code* is nearly trivial;

Defining it in a standard C90 header file or some extension
is equally as trivial, and would put it where it belongs, rather
than in every single fullscreen application.

> the only tricky part would be
> determining whether the current system uses EBCDIC..  But masking the
> character value will break on an EBCDIC system, where many printable
> characters have codes exceeding 0x7f.

And a C90-compliant program *already* shouldn't be doing
such masks, as C90 *already* allows for EBCDIC.

> (This is assuming there's any
> reason at all to make microemacs and msged support EBCDIC, something I'm
> very skeptical about.)

What editor would you like me to use on my mainframe
operating systems (z/PDOS and z/PDOS-generic) instead?
edlin?

I was using microemacs today on z/PDOS-generic to modify
my makefile.zpg in PDPCLIB, as I am now able to run the
entire toolchain to produce an executable. Actually I could
already do that previously, but now I can use standard
HLASM in the process.

> If you insist on using a language extension to support the Escape
> character, you could just copy gcc's '\e'.

That puts a burden on the compiler - every compiler,
basically - which is far from the trivial addition to an
existing header file, or a new header file, that I
suggested as an alternative.

BTW, the subject says 80386 C compiler, but I am likely
going to do S/370 (which also runs on z/Arch) at the same
time, as I realized that circumstances have changed such
that I can have a public domain suite for the mainframe
too if the compiler is covered. A bit of work would be
required to z/PDOS-generic to support the IFOX
MVS executables to cover the assembler. Unfortunately
the assembler is written in assembler instead of C (for
obvious historical reasons), but it's still public domain.

BFN. Paul.