Re: 80386 C compiler

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

"Paul Edwards" <mutazilah@gmail.com> writes:

"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.

>
I don't think that's a reasonable expectation, but it's your project,
so do what you like.
>

Microemacs and msged need them.

>
Do they?

>
How else do you propose providing a fullscreen interface?
>
We have a standard - ANSI X3.64.

>
It doesn't address EBCDIC.  If you want to create your own standard that
does, nobody is going to stop you.

EBCDIC ANSI is (or can be) identical to ASCII ANSI.
The same text is used to drive the screen. All the characters
have EBCDIC equivalents. They're all displayable ASCII
except for when the escape character is used - and that's
why I proposed adding a formal define for it - so that you
can drive a terminal in a portable manner.

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).

>
Apparently you think you need a language extension for something
you've already implemented.  Odd.

Depends on the definition of "need".

Yes I have it working. But it required conditional compilation
for the hex code of the ESC character. That's what I find odd.
That I can write an entire toolchain, including OS, portably
in C90, except for a smalll portion of the editor.

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:

>
It's from https://github.com/jrnutt/msged .

Thanks. That is msged 2.x. I am using msged 3.x. Which may
have been created after the original author disappeared,
presumably died.

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.

>
The (ancient and obsolete) 1990 ISO C standard does not support your
expectation.

It comes very very close. I'm just trying to eliminate that gap
with a reasonable extension.

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.

>
OK, you have your opinion about where it "belongs".  I won't continue
arguing about it.
>

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.

>
Or for any other character set that satisifies a few requirements, and
which may or may not have a character called "escape".

Correct - so I would be introducing something stricter than
C90 - a requirement for the character set to include an ESC,
so that an ANSI terminal can be driven.

And I think there is no avoiding a set of control keys so that
the microemacs keystrokes can be supported.

So yeah - ASCII and EBCDIC would both qualify. Other
theoretical character sets would be supported too. But yes,
some other real or theoretical character sets would not be
supported, so you can't use "the" portable version of
microemacs to drive an attached ANSI terminal.

Apparently by "C90-compliant" you mean "100% portable", which is
certainly not what I mean by it.

Well - "strictly conforming" is the proper term I believe.

I want to be strictly conforming to something close to C90
that takes into consideration the need for fullscreen apps
on another ANSI standard (X3.64).

The source code for microemacs and
msged is not 100% portable.  If you want to work on making it so, knock
yourself out.

Right - that's exactly what I'm doing. But I cannot do so if I
need to hardcode the code point of the ESC character.

Something has to give.

(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?

>
Use any editor you like.  You've now said you already have a working
microemacs for mainframe operating systems.

For 2 somewhat independent (rewrites) mainframe operating systems, yes.

It should be possible to get them to work under other mainframe
operating systems (ie MVS TSO) too, with an appropriate
attached terminal (likely emulated by a PC as is almost
universally done now). Would likely work on z/OS USS or
whatever it is called too, but I've never investigated that.

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.

>
What do you mean by "every compiler"?  I thought all you cared
about was a (currently nonexistent) public domain C90 compiler.

No. I care about all compilers.

The (work in progress) public domain ones satisfy one thing.

But I want to be able to go to any compiler I happen to be
using and add the necessary C90-X3.64-and-possibly-others
extensions.

Note that it is only by emperical testing that I found that the
only thing I needed was extensions for X3.64. But it is
possible that I have missed something and I would like
C90 extended to support some other ANSI standard
(or something else). Before the emperical results were in
I certainly didn't know what the limits of C90 were. Oh
yeah - in support of the FAT filesystem I have some
conditional compilation between ASCII and EBCDIC
too. To mark the file as "deleted". So possibly I need to
(in principle at least), change the FAT filesystem delete
character to something defined in C90+X3.64.

Note that z/PDOS-generic has a FAT file system in EBCDIC.
The EBCDIC character is what you get from what I consider
to be a definitive 819/1047 translation in Hercules.

BFN. Paul.