Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #151935 > unrolled thread
| Started by | Paul Edwards <mutazilah@gmail.com> |
|---|---|
| First post | 2020-05-01 22:19 -0700 |
| Last post | 2020-05-18 13:25 +1200 |
| Articles | 20 on this page of 188 — 19 participants |
Back to article view | Back to comp.lang.c
pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-01 22:19 -0700
Re: pure C90 environment fir <profesor.fir@gmail.com> - 2020-05-02 01:24 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-02 01:56 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-02 02:06 -0700
Re: pure C90 environment shi84516584@gmail.com - 2020-05-19 17:53 -0700
Re: pure C90 environment fir <profesor.fir@gmail.com> - 2020-05-02 02:07 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-02 02:23 -0700
Re: pure C90 environment shi84516584@gmail.com - 2020-05-19 17:55 -0700
Re: pure C90 environment Philipp Klaus Krause <pkk@spth.de> - 2020-05-02 11:05 +0200
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-02 02:14 -0700
Re: pure C90 environment antispam@math.uni.wroc.pl - 2020-05-03 22:33 +0000
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-03 16:18 -0700
Re: pure C90 environment antispam@math.uni.wroc.pl - 2020-05-04 00:35 +0000
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-03 17:54 -0700
Re: pure C90 environment Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-03 18:38 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-03 18:51 -0700
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-04 09:36 +0200
Re: pure C90 environment James Harris <james.harris.1@gmail.com> - 2020-05-04 08:48 +0100
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-04 01:12 -0700
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-04 15:16 +0200
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-04 06:21 -0700
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-04 15:40 +0200
Re: pure C90 environment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-05-04 07:12 -0700
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-04 14:47 +0100
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-04 07:08 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-04 08:12 -0700
Re: pure C90 environment BGB <cr88192@gmail.com> - 2020-05-05 11:36 -0500
Re: pure C90 environment James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-05-19 11:25 -0400
Re: pure C90 environment James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-05-19 11:39 -0400
Re: pure C90 environment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-05-19 08:45 -0700
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-19 17:43 +0200
Re: pure C90 environment James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-05-19 12:35 -0400
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-19 20:14 +0200
Re: pure C90 environment James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-05-19 14:42 -0400
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-19 12:11 -0700
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-19 21:46 +0200
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-19 13:11 -0700
Re: pure C90 environment Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-19 14:39 -0700
Re: pure C90 environment Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-19 13:24 -0700
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-20 09:26 +0200
Re: pure C90 environment antispam@math.uni.wroc.pl - 2020-05-19 21:11 +0000
Re: pure C90 environment James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-05-19 18:51 -0400
Re: pure C90 environment antispam@math.uni.wroc.pl - 2020-05-19 23:26 +0000
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-20 09:33 +0200
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-04 11:49 +0100
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-04 04:00 -0700
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-04 17:58 +0100
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-04 10:18 -0700
Re: pure C90 environment Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-04 13:57 -0700
Re: pure C90 environment Bonita Montero <Bonita.Montero@gmail.com> - 2020-05-02 12:11 +0200
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-02 11:26 +0100
Re: pure C90 environment Bonita Montero <Bonita.Montero@gmail.com> - 2020-05-02 13:06 +0200
Re: pure C90 environment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-05-02 04:26 -0700
Re: pure C90 environment fir <profesor.fir@gmail.com> - 2020-05-02 04:53 -0700
Re: pure C90 environment Bonita Montero <Bonita.Montero@gmail.com> - 2020-05-02 16:21 +0200
Re: pure C90 environment fir <profesor.fir@gmail.com> - 2020-05-02 11:20 -0700
Re: pure C90 environment Bonita Montero <Bonita.Montero@gmail.com> - 2020-05-02 16:20 +0200
Re: pure C90 environment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-05-02 07:33 -0700
Re: pure C90 environment Bonita Montero <Bonita.Montero@gmail.com> - 2020-05-02 16:35 +0200
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-02 17:30 +0100
Re: pure C90 environment Bonita Montero <Bonita.Montero@gmail.com> - 2020-05-02 18:37 +0200
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-02 18:18 +0100
Re: pure C90 environment Bonita Montero <Bonita.Montero@gmail.com> - 2020-05-02 19:25 +0200
Re: pure C90 environment Bonita Montero <Bonita.Montero@gmail.com> - 2020-05-02 19:25 +0200
Re: pure C90 environment Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-05-02 22:45 +0100
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-02 23:29 +0100
Re: pure C90 environment Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-05-03 03:55 +0100
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-03 13:07 +0100
Re: pure C90 environment fir <profesor.fir@gmail.com> - 2020-05-03 05:24 -0700
Re: pure C90 environment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-05-03 05:26 -0700
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-03 14:27 +0100
Re: pure C90 environment Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-05-03 22:38 +0100
Re: pure C90 environment Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-05-03 22:06 +0100
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-04 00:28 +0100
Re: pure C90 environment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-05-03 02:16 -0700
Re: pure C90 environment Öö Tiib <ootiib@hot.ee> - 2020-05-03 16:23 -0700
Re: pure C90 environment Bonita Montero <Bonita.Montero@gmail.com> - 2020-05-04 16:41 +0200
Re: pure C90 environment Bonita Montero <Bonita.Montero@gmail.com> - 2020-05-04 16:59 +0200
Re: pure C90 environment Öö Tiib <ootiib@hot.ee> - 2020-05-04 11:01 -0700
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-02 11:13 +0100
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-02 03:53 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-02 05:14 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-02 06:30 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-02 12:49 -0700
Re: pure C90 environment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-05-13 03:01 -0700
Re: pure C90 environment scott@slp53.sl.home (Scott Lurndal) - 2020-05-13 14:43 +0000
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-17 06:30 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-17 05:41 -0700
Re: pure C90 environment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-05-17 13:02 -0700
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-17 22:47 +0200
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-17 14:03 -0700
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-18 08:54 +0200
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-18 06:11 -0700
Re: pure C90 environment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-05-18 06:51 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-18 07:12 -0700
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-18 15:47 +0100
Re: pure C90 environment Manfred <noname@add.invalid> - 2020-05-18 16:25 +0200
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-18 07:41 -0700
Re: pure C90 environment Manfred <noname@add.invalid> - 2020-05-18 17:32 +0200
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-18 17:09 +0200
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-18 08:52 -0700
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-18 17:05 +0100
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-18 09:18 -0700
Re: pure C90 environment scott@slp53.sl.home (Scott Lurndal) - 2020-05-18 19:55 +0000
Re: pure C90 environment Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-05-19 01:42 +0100
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-18 20:35 -0700
Re: pure C90 environment scott@slp53.sl.home (Scott Lurndal) - 2020-05-19 16:12 +0000
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-19 10:02 -0700
Re: pure C90 environment scott@slp53.sl.home (Scott Lurndal) - 2020-05-19 17:42 +0000
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-19 18:16 +0100
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-19 13:00 +0200
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-19 05:09 -0700
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-19 15:20 +0100
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-19 08:18 -0700
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-19 17:58 +0100
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-19 10:45 -0700
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-19 19:31 +0100
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-19 11:58 -0700
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-19 20:44 +0100
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-19 13:03 -0700
Re: pure C90 environment antispam@math.uni.wroc.pl - 2020-05-19 22:34 +0000
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-19 15:41 -0700
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-20 00:03 +0100
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-19 16:10 -0700
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-20 01:46 +0100
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-19 22:49 -0700
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-20 11:26 +0100
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-20 04:43 -0700
Re: pure C90 environment Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-19 16:40 -0700
Re: pure C90 environment antispam@math.uni.wroc.pl - 2020-05-19 23:11 +0000
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-19 11:40 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-20 05:48 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-20 06:19 -0700
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-20 16:38 +0100
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-20 09:15 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-20 09:37 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-20 10:43 -0700
Re: pure C90 environment Öö Tiib <ootiib@hot.ee> - 2020-05-20 10:58 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-20 11:36 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-20 12:37 -0700
Re: pure C90 environment "muta...@gmail.com" <mutazilah@gmail.com> - 2021-03-10 17:43 -0800
Re: pure C90 environment "muta...@gmail.com" <mutazilah@gmail.com> - 2021-03-10 17:58 -0800
Re: pure C90 environment "muta...@gmail.com" <mutazilah@gmail.com> - 2021-03-10 18:03 -0800
Re: pure C90 environment "muta...@gmail.com" <mutazilah@gmail.com> - 2021-03-10 18:29 -0800
Re: pure C90 environment "muta...@gmail.com" <mutazilah@gmail.com> - 2021-03-10 19:54 -0800
Re: pure C90 environment "muta...@gmail.com" <mutazilah@gmail.com> - 2021-03-10 20:01 -0800
Re: pure C90 environment "muta...@gmail.com" <mutazilah@gmail.com> - 2021-03-10 20:04 -0800
Re: pure C90 environment "muta...@gmail.com" <mutazilah@gmail.com> - 2021-03-10 21:07 -0800
Re: pure C90 environment Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-03-10 23:10 -0800
Re: pure C90 environment "muta...@gmail.com" <mutazilah@gmail.com> - 2021-03-11 01:21 -0800
Re: pure C90 environment scott@slp53.sl.home (Scott Lurndal) - 2021-03-11 15:26 +0000
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-19 17:18 +0200
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-19 09:52 -0700
Re: pure C90 environment scott@slp53.sl.home (Scott Lurndal) - 2020-05-19 17:39 +0000
Re: pure C90 environment scott@slp53.sl.home (Scott Lurndal) - 2020-05-19 16:17 +0000
Re: pure C90 environment Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-05-19 22:54 +0100
Re: pure C90 environment Ian Collins <ian-news@hotmail.com> - 2020-05-20 10:17 +1200
Re: pure C90 environment Manfred <noname@add.invalid> - 2020-05-19 16:28 +0200
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-19 17:30 +0200
Re: pure C90 environment Manfred <noname@add.invalid> - 2020-05-19 19:39 +0200
Re: pure C90 environment antispam@math.uni.wroc.pl - 2020-05-18 15:12 +0000
Re: pure C90 environment scott@slp53.sl.home (Scott Lurndal) - 2020-05-18 19:51 +0000
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-18 13:02 -0700
Re: pure C90 environment Manfred <noname@add.invalid> - 2020-05-18 15:52 +0200
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-18 17:15 +0200
Re: pure C90 environment antispam@math.uni.wroc.pl - 2020-05-18 20:10 +0000
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-18 13:18 -0700
Re: pure C90 environment antispam@math.uni.wroc.pl - 2020-05-18 23:21 +0000
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-19 13:21 +0200
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-19 13:12 +0200
Re: pure C90 environment scott@slp53.sl.home (Scott Lurndal) - 2020-05-19 16:21 +0000
Re: pure C90 environment scott@slp53.sl.home (Scott Lurndal) - 2020-05-18 19:48 +0000
Re: pure C90 environment scott@slp53.sl.home (Scott Lurndal) - 2020-05-18 19:47 +0000
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-19 13:23 +0200
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-17 13:54 -0700
Re: pure C90 environment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-05-17 16:45 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-17 17:27 -0700
Re: pure C90 environment antispam@math.uni.wroc.pl - 2020-05-18 14:44 +0000
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-18 08:17 -0700
Re: pure C90 environment antispam@math.uni.wroc.pl - 2020-05-18 21:39 +0000
Re: pure C90 environment scott@slp53.sl.home (Scott Lurndal) - 2020-05-18 21:58 +0000
Re: pure C90 environment Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-18 16:40 -0700
Re: pure C90 environment scott@slp53.sl.home (Scott Lurndal) - 2020-05-19 00:22 +0000
Re: pure C90 environment antispam@math.uni.wroc.pl - 2020-05-19 00:27 +0000
Re: pure C90 environment scott@slp53.sl.home (Scott Lurndal) - 2020-05-19 16:10 +0000
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-18 14:59 -0700
Re: pure C90 environment scott@slp53.sl.home (Scott Lurndal) - 2020-05-18 20:01 +0000
Re: pure C90 environment Ian Collins <ian-news@hotmail.com> - 2020-05-18 13:25 +1200
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
| From | "muta...@gmail.com" <mutazilah@gmail.com> |
|---|---|
| Date | 2021-03-10 17:43 -0800 |
| Message-ID | <a2823502-d73f-4c34-9282-8142246cdb84n@googlegroups.com> |
| In reply to | #152433 |
Hi all.
I previously discussed setting up a pure C90 environment,
where the OS etc are all in C.
I have a new suggestion I'd like comment on.
I'd like to put the C library inside the OS, so that
applications just need to link with small stub
libraries. I realized that to do this I would need to
stop using static/global variables in my C library.
On the environment I am most familiar with, S/3X0,
I can maintain a CRAB (C runtime anchor block) on
the stack (it gets copied on every call) so that all
C functions have access to a dynamically allocated
block containing all the previously global/static data.
It occurred to me that applications might like to do
that themselves, rather than passing a big malloced
area as a parameter on every function call. I think
C90 should have provided a void **appCRAB() function
call which can potentially provide a location within
the CRAB. It doesn't matter if the actual implementation
is just a pointer to a normal global variable. What
include file (if any) should this function go in? stddef.h?
stdlib.h?
The CRAB used by the C library itself can perhaps be
returned by function/macro __getCRAB().
Next, to implement fopen(), it should simply be a call
to __osfunc(OS_FOPEN, filename, mode);
The app can also do the call directly, with
osfunc(OS_FOPEN, filename, mode);
to allow other non-C90 functions to be called.
OS_FOPEN will be part of an enum
osfunc may simply be a #define to __osfunc
The interface to the BIOS (ie used by the OS itself) will
also be defined the same way. ie while the OS may
support an fopen("config.sys"), the BIOS may support
fopen("0x1b0") which accesses raw device ID 0x1b0,
which contains a FAT-16 drive.
Because of these conflicting uses of fopen() by the OS
itself, fopen() will be reserved for OS-recognized files
like config.sys, while the BIOS must be accessed via
osfunc(OS_FOPEN, filename, mode);
With this in place, we now have the issue of a 32-bit
application requesting services of a 64-bit OS. The
same applies to other differences such as 16/32 or
16/64. Let's stick with 32/64.
__osfunc() will get a 32-bit address (provided by the
OS) from the CRAB which is an address to call. This
address is not linked in to the executable, it is provided
by the OS. This is then called, and a 64-bit address is
retrieved from the CRAB. This is an address in the
64-bit OS. This function knows the function code
(OS_FOPEN) and adjusts parameters on the stack
so that a 32-bit long is extended with zeroes to be
a 64-bit long. And then a normal call is made to
fopen() the same as if a 64-bit program had
requested the call.
As well as adjusting size of longs, you can also
adjust endianness and even do a processor switch,
e.g. from 68000 to x64, assuming you have a 68000
co-processor (or the equivalent via an emulator).
The OS may need to assist with the switch from 32-bit
to 64-bit. In the case of z/Arch, 32-bit programs can
run perfectly fine in 64-bit mode, so no mode switching
is required. With z/Arch, the OS can allocate 8 GiB of
memory, to ensure there is a 4 GiB boundary, and then
set all the high 32-bits of registers to point to that 4
GiB boundary, giving the 32-bit application an entire
4 GiB for itself. And when that 32-bit application does
a system() to another 32-bit application, the new
application gets another 4 GiB all for itself.
Obviously existing BIOSes don't have an fopen() (yet!)
so a wrapper (perhaps provided by the OS) would need
to be put on the existing BIOS to give the desired interface.
Note that in the case of z/Arch, bios.c can be a simple
program that exports its existing C library functions that
open a flat file, enabling you to run an OS while still in
user mode. Other environments can do that too if the
program size is consistent (ie either all 32-bit or all
64-bit).
It is not expected that the OS itself would want to do
a __osfunc(OS_POSIX_READ) or somesuch (to access
its own implementation, not the BIOS's), it would
just directly call posix_read() if it has implemented such
a call.
Perhaps osfunc() should be a C90 extension too? With
the C90 library as predefines, and other functions
unspecified?
BFN. Paul.
[toc] | [prev] | [next] | [standalone]
| From | "muta...@gmail.com" <mutazilah@gmail.com> |
|---|---|
| Date | 2021-03-10 17:58 -0800 |
| Message-ID | <187cdc30-f30f-46a2-8541-1049f7b05bc8n@googlegroups.com> |
| In reply to | #159283 |
On Thursday, March 11, 2021 at 12:43:33 PM UTC+11, muta...@gmail.com wrote: > It occurred to me that applications might like to do > that themselves, rather than passing a big malloced > area as a parameter on every function call. I think > C90 should have provided a void **appCRAB() function > call which can potentially provide a location within > the CRAB. It doesn't matter if the actual implementation > is just a pointer to a normal global variable. What > include file (if any) should this function go in? stddef.h? > stdlib.h? Note that this is writing naturally-reentrant programs, which can then potentially be executed by multiple users simultaneously. BFN. Paul.
[toc] | [prev] | [next] | [standalone]
| From | "muta...@gmail.com" <mutazilah@gmail.com> |
|---|---|
| Date | 2021-03-10 18:03 -0800 |
| Message-ID | <2792f979-85b9-40f3-92f3-773fa6d664e3n@googlegroups.com> |
| In reply to | #159283 |
On Thursday, March 11, 2021 at 12:43:33 PM UTC+11, muta...@gmail.com wrote: > is required. With z/Arch, the OS can allocate 8 GiB of > memory, to ensure there is a 4 GiB boundary, and then > set all the high 32-bits of registers to point to that 4 > GiB boundary, giving the 32-bit application an entire > 4 GiB for itself. This model is basically 32:32 segmented memory. BFN. Paul.
[toc] | [prev] | [next] | [standalone]
| From | "muta...@gmail.com" <mutazilah@gmail.com> |
|---|---|
| Date | 2021-03-10 18:29 -0800 |
| Message-ID | <706780fc-8080-4a41-812e-b52a6ac7cf1an@googlegroups.com> |
| In reply to | #159285 |
I think the file system should record whether a file was opened as "w" or "wb" and then applications such as zip should read that and store that information. This way text files can be converted from EBCDIC to ASCII automatically. In addition, when zip runs on an EBCDIC system, it should record the fact that it was opened on an EBCDIC system so that people know the binary file may contain EBCDIC data. In fact, the file system should record an ASCII vs EBCDIC indicator for each file, so that you can mix them. Also there should be a macro in stdio.h to let you know which one a particular file is, and one to set it on output if you don't want the default. BFN. Paul.
[toc] | [prev] | [next] | [standalone]
| From | "muta...@gmail.com" <mutazilah@gmail.com> |
|---|---|
| Date | 2021-03-10 19:54 -0800 |
| Message-ID | <677dc897-8c15-4b77-a3b0-814f5e87756bn@googlegroups.com> |
| In reply to | #159286 |
On Thursday, March 11, 2021 at 1:29:33 PM UTC+11, muta...@gmail.com wrote: > In fact, the file system should record an ASCII vs > EBCDIC indicator for each file, so that you can mix > them. Also there should be a macro in stdio.h to > let you know which one a particular file is, and one > to set it on output if you don't want the default. I think we need a three-way text file - A = Unix style, E = Unix style except in EBCDIC, L= local text style. And for dealing with text data in binary files, we need a foreign_to_local() function to convert a buffer. Neither side (ASCII users or EBCDIC users) are interested in what the foreigner is. :-) Obviously minimal implementations are free to make that function a no-op. BFN. Paul.
[toc] | [prev] | [next] | [standalone]
| From | "muta...@gmail.com" <mutazilah@gmail.com> |
|---|---|
| Date | 2021-03-10 20:01 -0800 |
| Message-ID | <1097ea9c-87bb-46fd-ac52-3b9d2551fcafn@googlegroups.com> |
| In reply to | #159287 |
On Thursday, March 11, 2021 at 2:54:40 PM UTC+11, muta...@gmail.com wrote: > And for dealing with text data in binary files, we > need a foreign_to_local() function to convert a > buffer. It can take as a parameter an "int foreign_code" returned by fgetforeign(FILE); in case people have Commodore PET data or something BFN. Paul.
[toc] | [prev] | [next] | [standalone]
| From | "muta...@gmail.com" <mutazilah@gmail.com> |
|---|---|
| Date | 2021-03-10 20:04 -0800 |
| Message-ID | <7d9dc02b-4e3d-4e54-9a2c-df7a6be3d328n@googlegroups.com> |
| In reply to | #159288 |
Another essential thing is to support \e in strings and characters to support the ESC code so that people can drive ANSI terminals, regardless of whether they are ASCII ANSI terminals or EBCDIC ANSI terminals. So it's no longer "pure C90", it's "pure C90+". BFN. Paul.
[toc] | [prev] | [next] | [standalone]
| From | "muta...@gmail.com" <mutazilah@gmail.com> |
|---|---|
| Date | 2021-03-10 21:07 -0800 |
| Message-ID | <8db5e084-f37d-4d9e-ba64-fc3272a8b69dn@googlegroups.com> |
| In reply to | #159289 |
Binary files should come with a two-way conversion
program. Both foreign_to_local() and local_to_foreign()
can be called on text data. So here is what the directory
entry for a FAT looks like:
/*Structure for Directory Entry */
typedef struct {
unsigned char file_name[8]; /*Short file name (0x00)*/
unsigned char file_ext[3]; /*Short file extension (0x08)*/
unsigned char file_attr; /*file attributes (0x0B)*/
unsigned char extra_attributes; /*extra attributes (0x0C)*/
unsigned char first_char; /*first character of deleted file
(0x0D)*/
unsigned char create_time[2]; /*create time(0x0E)*/
unsigned char create_date[2]; /*create date(0x10)*/
unsigned char last_access[2]; /*last access (0x12)*/
unsigned char access_rights[2]; /*file access rights (0x14)
*2 high bytes of start cluster (fat32)*/
unsigned char last_modtime[2]; /*last modified time (0x16)*/
unsigned char last_moddate[2]; /*last modified date (0x18)*/
unsigned char start_cluster[2]; /*Size of file in clusters (0x1A)*/
unsigned char file_size[4]; /*Size of file in bytes (0x1C) */
}DIRENT;
Only the file_name and file_ext and first_char should go
through the conversion process.
That's if you have a FAT-16 image file for example.
local_to_foreign() could be implementation-defined as to
what the foreign format is, and may be driven by an
environment variable in some implementation.
BFN. Paul.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-03-10 23:10 -0800 |
| Message-ID | <877dmei2rt.fsf@nosuchdomain.example.com> |
| In reply to | #159289 |
"muta...@gmail.com" <mutazilah@gmail.com> writes:
> Another essential thing is to support \e in strings
> and characters to support the ESC code so that
> people can drive ANSI terminals, regardless of
> whether they are ASCII ANSI terminals or EBCDIC
> ANSI terminals.
>
> So it's no longer "pure C90", it's "pure C90+".
Are there any "EBCDIC ANSI terminals", meaning terminals that handle
ANSI-style escape sequences, but with the ESC character represented as
0x27 rather than 0x1b and so forth? I've never heard of such a thing.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | "muta...@gmail.com" <mutazilah@gmail.com> |
|---|---|
| Date | 2021-03-11 01:21 -0800 |
| Message-ID | <c39acc9e-d1cb-481e-bb97-e4ec82a94836n@googlegroups.com> |
| In reply to | #159294 |
On Thursday, March 11, 2021 at 6:10:55 PM UTC+11, Keith Thompson wrote: > > Another essential thing is to support \e in strings > > and characters to support the ESC code so that > > people can drive ANSI terminals, regardless of > > whether they are ASCII ANSI terminals or EBCDIC > > ANSI terminals. > > > > So it's no longer "pure C90", it's "pure C90+". > Are there any "EBCDIC ANSI terminals", meaning terminals that handle > ANSI-style escape sequences, but with the ESC character represented as > 0x27 rather than 0x1b and so forth? I've never heard of such a thing. As far as I know, that hardware has never been built, but PDOS/3X0 (running on mainframe, using EBCDIC) successfully drives an EBCDIC ANSI terminal and you can thus run micro-emacs under it (after building a mainframe EBCDIC micro-emacs executable with the ANSI target). Using the Hercules/380 emulator. Modifications to micro-emacs were required to support EBCDIC. But not a lot. BFN. Paul.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-03-11 15:26 +0000 |
| Message-ID | <fEq2I.44$rU.39@fx39.iad> |
| In reply to | #159294 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >"muta...@gmail.com" <mutazilah@gmail.com> writes: >> Another essential thing is to support \e in strings >> and characters to support the ESC code so that >> people can drive ANSI terminals, regardless of >> whether they are ASCII ANSI terminals or EBCDIC >> ANSI terminals. >> >> So it's no longer "pure C90", it's "pure C90+". > >Are there any "EBCDIC ANSI terminals", meaning terminals that handle >ANSI-style escape sequences, but with the ESC character represented as >0x27 rather than 0x1b and so forth? I've never heard of such a thing. > Even on the EBCDIC Burroughs mainframes, the terminals all spoke ASCII-63.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-05-19 17:18 +0200 |
| Message-ID | <ra0tbf$f9g$1@dont-email.me> |
| In reply to | #152369 |
On 19/05/2020 14:09, Paul Edwards wrote: > On Tuesday, 19 May 2020 21:00:51 UTC+10, David Brown wrote: > >>> I am not aware of any portable languages that were standardized by >>> ISO at the time that C90 was published, and are superior to C90. An >>> enormous amount of effort has gone into C90, allowing high >>> performance I/O to be done on both mainframe and PC with the same >>> source code. >> >> Add enough conditions to your requirements, and you will end up with >> only C90 fitting. > > It's not just my requirements. I mean your requirement for the language to pick for your project. That is entirely /your/ requirements. > >> It seems to me you are fine-tuning your question once >> you have decided on the answer you want. > > I was there in 1990 and there was no > competitor to C for developing > low-level code. Even if that is true, we are no longer in 1990. > >> (Throughout this post, I am trying to make you think about what you are >> doing, and consider the implications. Explaining things to someone else >> forces you to form a better understanding yourself. > > Sure. Thanks for teasing it out. As I have > already admitted, I only have a vague > sense of what I am trying to achieve. That is the bit I am trying to help with - my hope is that by answering the points I pose here, you might get a better idea of the project for yourself. > >>> I agree with that, but it's still the fact that you need to learn C90 >>> to get your ticket to the world. >> >> Nonsense. > > Nope. It's the one language you can code > in to have your code work everywhere. > Again, nonsense. Your claim here is completely different from your previous claim, and they are both nonsense. Let me elaborate a little. First, you said you "need to learn C90 to get your ticket to the world". Most programmers never learn C90, and do fine. Most /C/ programmers never really learn C90, and do fine - it is a long time since it was common for programs and programmers to be limited to C90. (It is still found in a few specific circumstances.) Very few people would ever choose C90 if they can work with C99 - or at least a partial C99 support (like MSVC has had until recently). Thus the idea that programmers need to learn C90 is nonsense. Next, you said that C90 is the "one language you can code in to have your code work everywhere". This is wrong in both senses. There are other languages that are portable to a range of systems (Java and Python are two examples). They won't work on such small systems as C, but are /hugely/ better for portability in many kinds of programming as they abstract OS features like networking, files, threads, graphics, etc. Secondly, as I have pointed out many times, using C90 does not make code portable - almost all real-world programs are at least somewhat system dependent. Pure standard-only C90 is simply not enough to be useful. >>> Because C90 hasn't been done to my satisfaction yet. >> >> C90 is a language, and has been implemented on a huge variety of >> systems. What aspect of it "has not been done yet" as far as you are >> concerned? > > The GCCMVS port, which is used by some people, > does not call IKJPARS to retrieve the file > prefix, preventing a longer prefix from > being provided by MVS/380. That's just one > example. That makes no sense to me - like most people, I am not familiar with the details of mainframe systems that were outdated 30 years ago. > Another example is SDCC not > supporting the "double" type. It was only > very recently that SDCC supported structure > assignment. I /still/ don't understand your complaints. You seem to be saying that these are two examples of C compilers (or C implementations - you are a little loose on the details here) that are not fully C90 standard compliant, or that don't have all the features you want. Are you bothered because there are some compilers that say they are C90 compilers but aren't fully conforming? I can think of many "C" compilers that are far further from being conforming than SDCC. Or are you bothered that there are some platforms for which there are no good C90 compilers? Again, there are many targets for which that is the case - many for which there is much less hope of a good C90 compiler than for the targets of SDCC. People don't need or want full C90 implementations for these sorts of systems. No one (rounded to the nearest handful of people) cares about new tools for a long outdated language for a long outdated OS on long outdated hardware. (They do care that existing tools and software continue to run on existing hardware, but that's a different matter.) No one much cares about 64-bit doubles on SDCC's targets - they know that it would be borderline insane to write code that uses them. > >> And it doesn't actually matter if you have C90 on everything from an >> 8051 to an IBM mainframe when there are no useful programs that can be >> run on both systems. In particular, you will never have a useful C90 >> compiler that can be compiled and hosted on anything targeted by SDCC. > > I don't have a requirement for a C90 > compiler to be *hosted* on a Z80, only > that it be *targetable*. I think it is > valid that GCC is a 3 MB module, as that > is what is required to do all the desired > optimization without kludging. Why a Z80? Why do you care that C runs on that chip? It was nice in its day, but that was long ago. What about, for example, AVR Tiny devices? These are used /now/, and you can compile code for them with gcc - but it will not be fully conforming (when you have an 8-bit device with 64 bytes ram, you don't worry about 64-bit doubles). What about Atmel MARC4 chips or EPSON S1C6x devices? These were made in their billions, but never had a C compiler. > >> I am asking /you/. I know why the BSD and GPL fans (at least, the >> informed ones - some people pick those licenses without thinking) pick >> the licenses they do. I am asking /you/ what /you/ think people can do >> with your code if you release it as "public domain", that they could not >> do if it were released under a BSD or GPL type of license. What do you >> think people will want to do with it? What do /you/ want them to do >> with it? > > I want commercial operations to be able to > pick up the code and write closed-source > proprietary versions of the software which > they can sell, with reduced input costs. They can do that if you use a BSD license. MacOS, for example, is fully closed source and the kernel is a copy of the BSD-licensed FreeBSD. Often, companies will blankly refuse to make use of public domain code because its source cannot be traced - they never know if they have a right to use it, or if someone will make legal claims against them. And in some countries the concept simply doesn't make sense, because you cannot disclaim your rights and therefore you can't have software that is not copyrighted. It would seem that again, you are stuck 30 years in the past. > I've described it more here: > > https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpgoal.txt > >> Do you mind that they can do things that you /don't/ want them >> to be able to do? > > There is nothing that I don't want them to do. So you are fine that others claim credit for your work? > >> Possession is nine tenths of the law. If someone takes your public >> domain code and puts their own copyright on it, they can happily say in >> court that you threw it away as worthless, and gave up all your rights >> to it. "Moral rights" are irrelevant. > > I *did* give up all my rights to it - to the > public. It's not worthless, it's gifted to > the public. That's what public domain means. > Not exactly, no. I recommend you talk to someone who knows a little of the law here before you do something you might regret. (And before this gets too off-topic for this group.) You are very much mixing up usage rights and ownership rights. >>> GCC 3.2.3 is a 3 MB executable. I expect this to be able to run, >>> instead of having kludges to squeeze a sub-standard compiler on to >>> inappropriate hardware. So to me, the world begins with 32-bit >>> processors. >> >> Right. So SDCC and other small-system embedded compilers /are/ >> irrelevant to you. > > So long as they are hosted on 32-bit systems, > they are not irrelevant. > >> As are lots of other C90 compilers and targets - >> including perfectly good working C90 compilers for 16-bit systems like DOS. > > I don't have a requirement that people use > kludges to fit their compilers into 16 bits. > >> It is quite reasonable for a modern system to put 32-bit as the lowest >> requirement. But I question putting the 80386 as the lowest requirement >> - that is an arbitrary choice that is long outdated. If you had said >> 32-bit ARM or 32-bit RISC-V, it would have made more sense, as those are >> architectures that are important today. > > I want to be able to run on a PC that has > been booted from USB stick. It is the PC > that is ubiquitous. > >>> The world has moved on with fads, without first securing C90, in my >>> opinion. >> >> As before, I do not understand what you mean by that. And as well as >> trying to explain what "securing C90" means, try to explain why it matters. > > It is a house built on sand in my opinion. > The public doesn't own the means to process > C code. It's all copyrighted by various > people. We're still many decades from the > work transitioning into the public domain, > which happens for a reason. Basically, you are trying to say is that you think there should be some sort of C90 compiler that runs on a PC, where the compiler code is "public domain" (a term that I don't believe you fully understand) ? And this compiler, or set of compilers, should be able to generate code for 80386, Z80A, and some dead mainframe? > > I can remember a comment from someone that > there should be a special clause for software, > that it should enter the public domain after > 10 years, because anything more than that > and it may as well be forever. > >> The world /does/ move on. History can be interesting, and backwards >> compatibility is important, but trying to re-create the past is rarely >> useful. > > I'm not sure I'm recreating the past. I'm trying > to secure a particular level of technology with > a public domain implementation. And it needs to > be something that is achievable by me in my > lifetime. I can't spend thousands of man-years > to reimplement Windows 10. But a 32-bit version > of MSDOS is achievable. > There are plenty of OS's available, with source code and licenses that let people use them, modify them, distribute them, commercialise them, as they want. There are even some that are public domain, like TempleOS. Write your own OS if you like - I am sure it will be a fun challenge. But don't make the mistake of thinking it is something the world needs. >>>> If you want that, then C (C90 or otherwise) is not the language for >>>> you. It is a high level language, and is far from assembler. >>> >>> Sorry for my poor English. >> >> You are Australian, is that right? > > Yes, I just meant my English was poor in that > one sentence, not in general. > >>> I think we should be aiming for efficiency. >> >> I think you should forget about efficiency. It is contrary to your >> other goals. If people want to generate efficient object code, they >> should not be using an ancient compiler with an outdated language - they >> should be using a modern compiler with a modern language. You are not >> going to write a C90 compiler that fits on all your systems and >> generates 80386 code that comes close to what can be achieved with C99 >> on gcc 10 or the latest clang, tuned for a modern processor. > > First I want to actually have a public domain > implementation of a C compiler. Then I want > to make it more efficient, including being > able *as an option* to target a modern processor, > as well as the 6502 etc. > >>> Ok, but I want to be able to describe 80386SX processors so that the >>> hardware guys with the valves know what to be working towards. >> >> /Please/ don't! The 80386SX is a crap architecture extended in >> inconsistent and inefficient ways and then cut down again in different >> ways. It is /horrible/ for implementing. >> >> If you want to pick an architecture that is well-suited to C, is 32-bit, >> and can be implemented relatively easily in a variety of ways, then >> RISC-V is probably the best choice. > > Ok. Thanks for the pointer. But I still want > to finish implementing the 80386 and S/3X0 > and probably ARM before porting to RISC-V. > I want to be able to get a job on any of > these popular platforms and be able to take > my toolkit with me. I know what it is like > turning up to a new job and not having a > C compiler available and having to write > in assembler instead. I'm not asking for > the latest greatest fad. I'm just asking > for C90 to be made available everywhere. > I don't think that is too much to ask for. > It is the standard language for computers, > since 1990. > I can't imagine many jobs in programming now where you would be asked to, or even allowed to, program in C90. (Such jobs exist, but they are rare.) There would be even fewer where it would be acceptable to use your own home-made compiler - certainly not for anything on x86, mainframes or ARM devices.
[toc] | [prev] | [next] | [standalone]
| From | Paul Edwards <mutazilah@gmail.com> |
|---|---|
| Date | 2020-05-19 09:52 -0700 |
| Message-ID | <7d7ea68f-c65f-46a1-b3bb-869e993550d3@googlegroups.com> |
| In reply to | #152372 |
On Wednesday, 20 May 2020 01:18:17 UTC+10, David Brown wrote: > >> Add enough conditions to your requirements, and you will end up with > >> only C90 fitting. > > > > It's not just my requirements. > > I mean your requirement for the language to pick for your project. That > is entirely /your/ requirements. Well, that started around 1987 when I was starting out and asked someone who seemed to know a lot about computers what the best programming language was. He asked me what I wanted to do. And I said I wanted my code to work on any computer, including future computers. He told me "C". So I started looking into that, confirmed that it was usable for low-level work, but wasn't yet standardized, but was about to be. At least one person in the Fidonet C_ECHO group said that he was holding back on using ANSI C until it was actually ratified. And I was working on mainframes at the time so I wanted C for that too. It took an awful long time for me to get to the bottom of how to implement C on MVS. It is only a couple of years ago that I figured out how to make the same executable work on both MVS 3.8J and z/OS, executing as 31-bit on z/OS. And it's still not finished. I'm still not satisfied with the C90 implementation. > >> It seems to me you are fine-tuning your question once > >> you have decided on the answer you want. > > > > I was there in 1990 and there was no > > competitor to C for developing > > low-level code. > > Even if that is true, we are no longer in 1990. And we still don't have a public domain solution for what existed in 1990. In 1990 I was dialing BBSes using Telix 3.15. I still don't have the equivalent of that running on MVS 3.8J. Or being able to run the BBS itself on MVS 3.8J. But I have an expectation of being able to use MVS as easily as MSDOS. I don't expect MVS to be inferior to MSDOS. > >> (Throughout this post, I am trying to make you think about what you are > >> doing, and consider the implications. Explaining things to someone else > >> forces you to form a better understanding yourself. > > > > Sure. Thanks for teasing it out. As I have > > already admitted, I only have a vague > > sense of what I am trying to achieve. > > That is the bit I am trying to help with - my hope is that by answering > the points I pose here, you might get a better idea of the project for > yourself. Yes, thankyou for bearing with me. :-) > >>> I agree with that, but it's still the fact that you need to learn C90 > >>> to get your ticket to the world. > >> > >> Nonsense. > > > > Nope. It's the one language you can code > > in to have your code work everywhere. > > Again, nonsense. Your claim here is completely different from your > previous claim, Well, almost everywhere. There are still some wallflowers, and I'm working on that. > First, you said you "need to learn C90 to get your ticket to the world". > Most programmers never learn C90, and do fine. Their code doesn't do fine. It won't run on MVS 3.8J and it won't run on the devices SDCC targets either. > Most /C/ programmers > never really learn C90, and do fine - it is a long time since it was > common for programs and programmers to be limited to C90. (It is still > found in a few specific circumstances.) Very few people would ever > choose C90 if they can work with C99 - or at least a partial C99 support > (like MSVC has had until recently). You've hit the nail on the head here. C99 is only partially supported, making it not universal. If anything is universal, it is C90, and even that is STILL not done to my satisfaction. > Thus the idea that programmers need to learn C90 is nonsense. > > Next, you said that C90 is the "one language you can code in to have > your code work everywhere". This is wrong in both senses. There are > other languages that are portable to a range of systems (Java and Python > are two examples). Java and Python only work because of the underlying supporting C code, right? And I haven't seen either on MVS 3.8J so far. > They won't work on such small systems as C, but are > /hugely/ better for portability in many kinds of programming as they > abstract OS features like networking, files, threads, graphics, etc. Relying on the C code to do that. And I don't think we should be using interpreted languages either. We should be aiming for assembler level efficiency. > Secondly, as I have pointed out many times, using C90 does not make code > portable - almost all real-world programs are at least somewhat system > dependent. Pure standard-only C90 is simply not enough to be useful. It comes very close, and I am building my entire development environment in C90, hence the subject of this thread. > >>> Because C90 hasn't been done to my satisfaction yet. > >> > >> C90 is a language, and has been implemented on a huge variety of > >> systems. What aspect of it "has not been done yet" as far as you are > >> concerned? > > > > The GCCMVS port, which is used by some people, > > does not call IKJPARS to retrieve the file > > prefix, preventing a longer prefix from > > being provided by MVS/380. That's just one > > example. > > That makes no sense to me - like most people, I am not familiar with the > details of mainframe systems that were outdated 30 years ago. I don't consider them to be outdated. People are still using them, and those people can and do report/fix bugs in PDPCLIB, making it a better product, even if you run PDPCLIB on an 80386 instead. And C90 was designed to work on mainframes too, and it does an excellent job of that. > > Another example is SDCC not > > supporting the "double" type. It was only > > very recently that SDCC supported structure > > assignment. > > I /still/ don't understand your complaints. You seem to be saying that > these are two examples of C compilers (or C implementations - you are a > little loose on the details here) that are not fully C90 standard > compliant, or that don't have all the features you want. > > Are you bothered because there are some compilers that say they are C90 > compilers but aren't fully conforming? They don't claim to be C90. They explicitly mention where they fall short of C90 compliance. I would rather the ISO C99 committee spent more time assisting with SDCC development than coming up with new pie in the sky requirements for compilers to conform to. > Or are you bothered that there are some platforms for which there are no > good C90 compilers? Again, there are many targets for which that is the > case - many for which there is much less hope of a good C90 compiler > than for the targets of SDCC. I want to do the best I can. To avoid the need to write in assembler as far as possible. So once I have a public domain C90 compiler I would like to target more and more environments, so that if you ever find a processor lying in a junkyard, you will be able to write software for it, without needing to write in assembler. I want to avoid people writing in assembler, because C90 is so much more productive, and gives similar results. Note that the folks at GCC were KEEN to DELETE the i370 target of GCC, whereas to me that was truly precious, targeting the S/370 machines. That is why I have stuck with GCC 3.2.3 and GCC 3.4.6. > People don't need or want full C90 implementations for these sorts of > systems. No one (rounded to the nearest handful of people) cares about > new tools for a long outdated language for a long outdated OS on long > outdated hardware. (They do care that existing tools and software > continue to run on existing hardware, but that's a different matter.) > No one much cares about 64-bit doubles on SDCC's targets - they know > that it would be borderline insane to write code that uses them. I don't mind if the double is the same as float. I just have code that uses double and I expect it to compile and run. > > I don't have a requirement for a C90 > > compiler to be *hosted* on a Z80, only > > that it be *targetable*. I think it is > > valid that GCC is a 3 MB module, as that > > is what is required to do all the desired > > optimization without kludging. > > Why a Z80? Why do you care that C runs on that chip? While ever it exists, I don't want people to have to write in assembler. I don't know Z80 assembler myself, but if I ever run across one, I want to know I can write a program for it. I hate writing in assembler. I'm probably 30 times more productive in C than assembler, but that is only the case if I am armed with a compiler. > It was nice in > its day, but that was long ago. What about, for example, AVR Tiny > devices? These are used /now/, and you can compile code for them with > gcc - but it will not be fully conforming (when you have an 8-bit device > with 64 bytes ram, you don't worry about 64-bit doubles). What about > Atmel MARC4 chips or EPSON S1C6x devices? These were made in their > billions, but never had a C compiler. Yes, I would like my C90 compiler to target all of these devices. 80386 is just a first step. > > I want commercial operations to be able to > > pick up the code and write closed-source > > proprietary versions of the software which > > they can sell, with reduced input costs. > > They can do that if you use a BSD license. MacOS, for example, is fully > closed source and the kernel is a copy of the BSD-licensed FreeBSD. I don't want the commercial enterprises to be required to keep my name in their derived product if they don't want to. The same as they don't need to credit Shakespeare when reusing "Hamlet". > Often, companies will blankly refuse to make use of public domain code > because its source cannot be traced - they never know if they have a > right to use it, or if someone will make legal claims against them. And That is not a problem I am trying to solve. > in some countries the concept simply doesn't make sense, because you > cannot disclaim your rights and therefore you can't have software that > is not copyrighted. I provide CC0 as a fallback for them. > It would seem that again, you are stuck 30 years in the past. When I was a kid, people were flailing about raising money for poor starving Africans. They're still flailing about today. I instead chose to disengage from the flailing and tried to work out what the root cause of the problem was, and solve that. That's what I'm doing with computers too. The market managed to produce working computers by 1990. They even had an agreed-upon language. Let's sit down and work out what we want, instead of flailing around with the latest fad language. How can hobbyists make best use of their free time that they are willing to donate? > > I've described it more here: > > > > https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpgoal.txt > > > >> Do you mind that they can do things that you /don't/ want them > >> to be able to do? > > > > There is nothing that I don't want them to do. > > So you are fine that others claim credit for your work? To the same extent that they can claim credit for Shakespeare's work, yes. I want them to totally own their modified version of my work. I don't want myself to have provided any barrier for them. If they want to imagine their own barriers, that's beyond my remit. > > It is a house built on sand in my opinion. > > The public doesn't own the means to process > > C code. It's all copyrighted by various > > people. We're still many decades from the > > work transitioning into the public domain, > > which happens for a reason. > > Basically, you are trying to say is that you think there should be some > sort of C90 compiler that runs on a PC, where the compiler code is > "public domain" (a term that I don't believe you fully understand) ? > And this compiler, or set of compilers, should be able to generate code > for 80386, Z80A, and some dead mainframe? Yes, but Z80 is not the priority. 80386, S/370 and ARM would be the priority. I want to reach people who are willing to donate code to the public domain, and those people (or companies) might be using ARM. > There are plenty of OS's available, with source code and licenses that > let people use them, modify them, distribute them, commercialise them, > as they want. There are even some that are public domain, like TempleOS. > > Write your own OS if you like - I am sure it will be a fun challenge. I already have written it, and it is already self-hosting. PDOS/386. > But don't make the mistake of thinking it is something the world needs. It is something I need so that people who like the concept of public domain can channel their efforts into PDOS instead of being forced to join one of the copyrighted projects because they don't wish to start from scratch. > I can't imagine many jobs in programming now where you would be asked > to, or even allowed to, program in C90. I want to take my tools with me to the job. My tools are written in C90. > (Such jobs exist, but they are > rare.) There would be even fewer where it would be acceptable to use > your own home-made compiler - certainly not for anything on x86, > mainframes or ARM devices. At one job I was working at, a customer was asking us to change the filename because they were having trouble processing it. I instead wrote a small C90-compliant program which returned a different return code depending on the contents of the file. I sent them the code, and said that if they didn't have a C compiler, they could use the free GCCMVS. The ability to do that - have a universal language - the computing equivalent of English for humans - makes it all worthwhile to me, even if the situation rarely arises. Just like the situation is rare that I will find a Z80 chip lying on the street that I wish to program. But do be aware of this: https://collapseos.org/ That guy is hoping for Z80 chips lying on the street. BFN. Paul.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2020-05-19 17:39 +0000 |
| Message-ID | <vRUwG.183617$cJ2.143104@fx47.iad> |
| In reply to | #152384 |
Paul Edwards <mutazilah@gmail.com> writes: > I don't expect MVS to be >inferior to MSDOS. faint praise, indeed.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2020-05-19 16:17 +0000 |
| Message-ID | <vETwG.71927$iB5.23173@fx06.iad> |
| In reply to | #152369 |
Paul Edwards <mutazilah@gmail.com> writes: >On Tuesday, 19 May 2020 21:00:51 UTC+10, David Brown wrote: > >> Add enough conditions to your requirements, and you will end up with >> only C90 fitting. > >It's not just my requirements. I was there >before C was standardized and can remember >someone saying that he was sticking with >K&R C until such time as ANSI C was >formally ratified. It was only after ANSI >was ratified, and then the international >community concurred, that we finally had >a standard language for computers in my >opinion. One silly person isn't evidence for anything. > >> It seems to me you are fine-tuning your question once >> you have decided on the answer you want. > >I was there in 1990 and there was no >competitor to C for developing >low-level code. I was there in 1979 when there were dozens of languages suitable for developing low-level code (Western Electric C, Burroughs BPL, HP-3000 SPL, Burroughs NEWP (Algol variant for writing operating systems, Burroughs SPRITE (Modula-like language used for OS and utility implementation), et. alia). >> >> If you want to pick an architecture that is well-suited to C, is 32-bit, >> and can be implemented relatively easily in a variety of ways, then >> RISC-V is probably the best choice. > >Ok. Thanks for the pointer. But I still want >to finish implementing the 80386 and S/3X0 >and probably ARM before porting to RISC-V. >I want to be able to get a job on any of >these popular platforms and be able to take >my toolkit with me. I know what it is like >turning up to a new job and not having a >C compiler available and having to write >in assembler instead. C'est what? When did you last show up for a new job? 1950?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-05-19 22:54 +0100 |
| Message-ID | <87lflnfv50.fsf@bsb.me.uk> |
| In reply to | #152369 |
Paul Edwards <mutazilah@gmail.com> writes: <cut> > I was there in 1990 and there was no > competitor to C for developing > low-level code. To the extent that that is true it is because K&R C had already "won" by then. I was there in 1990 as well, but I was also there in 1980 and I worked on low-level code written in BCPL and, later, in Pascal (of all things). These alternatives, and others, did not go away. <cut> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2020-05-20 10:17 +1200 |
| Message-ID | <hij47qFamcfU1@mid.individual.net> |
| In reply to | #152406 |
On 20/05/2020 09:54, Ben Bacarisse wrote: > Paul Edwards <mutazilah@gmail.com> writes: > <cut> >> I was there in 1990 and there was no >> competitor to C for developing >> low-level code. > > To the extent that that is true it is because K&R C had already "won" by > then. I was there in 1990 as well, but I was also there in 1980 and I > worked on low-level code written in BCPL and, later, in Pascal (of all > things). These alternatives, and others, did not go away. Same here, our company had complex system implemented in BCPL and we wrote what would be called embedded systems on PDP11s written in Pascal. Back in my schools days, we used a PDP11 with an OS written in a dialect of BASIC (https://en.wikipedia.org/wiki/BASIC-PLUS). So I learned my low level coding in BASIC... -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2020-05-19 16:28 +0200 |
| Message-ID | <ra0qdq$1du0$1@gioia.aioe.org> |
| In reply to | #152365 |
On 5/19/2020 1:00 PM, David Brown wrote: > Possession is nine tenths of the law. If someone takes your public > domain code and puts their own copyright on it, they can happily say in > court that you threw it away as worthless, and gave up all your rights > to it. "Moral rights" are irrelevant. I am no lawyer, however this sounds odd. I think copyright law is about the author's right, and it doesn't allow someone to pick up something and arbitrarily say "I made it" As an example, say a painter finds a Picasso in a trash bin. He can legitimately say "now it's mine" and sell it for good money, but he can't say "I made it".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-05-19 17:30 +0200 |
| Message-ID | <ra0u2v$rs9$1@dont-email.me> |
| In reply to | #152371 |
On 19/05/2020 16:28, Manfred wrote: > On 5/19/2020 1:00 PM, David Brown wrote: >> Possession is nine tenths of the law. If someone takes your public >> domain code and puts their own copyright on it, they can happily say in >> court that you threw it away as worthless, and gave up all your rights >> to it. "Moral rights" are irrelevant. > > I am no lawyer, however this sounds odd. I think copyright law is about > the author's right, and it doesn't allow someone to pick up something > and arbitrarily say "I made it" That is very much what copyright law is about. But releasing something as "public domain" is saying "I don't want the copyright to this, I'm throwing away that right". (I am no lawyer either.) > > As an example, say a painter finds a Picasso in a trash bin. He can > legitimately say "now it's mine" and sell it for good money, but he > can't say "I made it".
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2020-05-19 19:39 +0200 |
| Message-ID | <ra15kf$1g1g$1@gioia.aioe.org> |
| In reply to | #152375 |
On 5/19/2020 5:30 PM, David Brown wrote: > On 19/05/2020 16:28, Manfred wrote: >> On 5/19/2020 1:00 PM, David Brown wrote: >>> Possession is nine tenths of the law. If someone takes your public >>> domain code and puts their own copyright on it, they can happily say in >>> court that you threw it away as worthless, and gave up all your rights >>> to it. "Moral rights" are irrelevant. >> >> I am no lawyer, however this sounds odd. I think copyright law is about >> the author's right, and it doesn't allow someone to pick up something >> and arbitrarily say "I made it" > > That is very much what copyright law is about. But releasing something > as "public domain" is saying "I don't want the copyright to this, I'm > throwing away that right". Not really, I think releasing to the public domain means that the author grants to everyone the right to use and modify his work. Granting exclusive use to someone else is also possible, but it is a different thing. This is to say that in order for someone to get exclusive right on someone else's work they should be granted such exclusive right from the author, which is different from the author granting the right to everybody. > > (I am no lawyer either.) Just guessing as well... > >> >> As an example, say a painter finds a Picasso in a trash bin. He can >> legitimately say "now it's mine" and sell it for good money, but he >> can't say "I made it". >
[toc] | [prev] | [next] | [standalone]
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web