Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #389052 > unrolled thread

80386 C compiler

Back to article view | Back to comp.lang.c

Contents

  80386 C compiler "Paul Edwards" <mutazilah@gmail.com> - 2024-11-24 22:00 +0800
    Re: 80386 C compiler fir <profesor.fir@gmail.com> - 2024-11-24 18:51 +0100
      Re: 80386 C compiler fir <profesor.fir@gmail.com> - 2024-11-24 18:58 +0100
        Re: 80386 C compiler "Paul Edwards" <mutazilah@gmail.com> - 2024-11-25 08:00 +0800
      Re: 80386 C compiler Bart <bc@freeuk.com> - 2024-11-24 18:00 +0000
        Re: 80386 C compiler BGB <cr88192@gmail.com> - 2024-11-24 17:46 -0600
          Re: 80386 C compiler "Paul Edwards" <mutazilah@gmail.com> - 2024-11-25 08:15 +0800
    Re: 80386 C compiler Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-24 19:52 +0100
      Re: 80386 C compiler "Paul Edwards" <mutazilah@gmail.com> - 2024-11-25 07:46 +0800
        Re: 80386 C compiler Kaz Kylheku <643-408-1753@kylheku.com> - 2024-11-25 18:23 +0000
          Re: 80386 C compiler Rosario19 <Ros@invalid.invalid> - 2024-11-25 22:14 +0100
            Re: 80386 C compiler Kaz Kylheku <643-408-1753@kylheku.com> - 2024-11-26 17:59 +0000
              Re: 80386 C compiler Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-26 13:05 -0800
                Re: 80386 C compiler "Paul Edwards" <mutazilah@gmail.com> - 2024-11-27 05:30 +0800
                  Re: 80386 C compiler Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-26 14:27 -0800
                    Re: 80386 C compiler "Paul Edwards" <mutazilah@gmail.com> - 2024-11-27 13:23 +0800
                      Re: 80386 C compiler Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-26 21:59 -0800
                        Re: 80386 C compiler "Paul Edwards" <mutazilah@gmail.com> - 2024-11-27 21:50 +0800
                Re: 80386 C compiler Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-27 16:45 -0800
              Re: 80386 C compiler David Brown <david.brown@hesbynett.no> - 2024-11-27 11:00 +0100
                Re: 80386 C compiler Kaz Kylheku <643-408-1753@kylheku.com> - 2024-11-27 19:42 +0000
                  Re: 80386 C compiler James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-27 14:59 -0500
                    Re: 80386 C compiler Kaz Kylheku <643-408-1753@kylheku.com> - 2024-11-27 21:52 +0000
                      Re: 80386 C compiler James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-27 18:07 -0500
                        Re: 80386 C compiler Kaz Kylheku <643-408-1753@kylheku.com> - 2024-11-30 01:30 +0000
                          Re: 80386 C compiler Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-29 21:00 -0800
                          Re: 80386 C compiler James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-30 09:00 -0500
                  Re: 80386 C compiler David Brown <david.brown@hesbynett.no> - 2024-11-28 09:12 +0100
              Re: 80386 C compiler Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-27 19:26 -0800
              Re: 80386 C compiler Rosario19 <Ros@invalid.invalid> - 2024-11-30 16:41 +0100
          Re: 80386 C compiler "Paul Edwards" <mutazilah@gmail.com> - 2024-11-26 10:48 +0800
    Re: 80386 C compiler Lynn McGuire <lynnmcguire5@gmail.com> - 2024-11-25 15:55 -0600
      Re: 80386 C compiler Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-25 14:10 -0800
        Re: 80386 C compiler Lynn McGuire <lynnmcguire5@gmail.com> - 2024-11-25 18:32 -0600
          Re: 80386 C compiler Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-25 16:49 -0800
            Re: 80386 C compiler BGB <cr88192@gmail.com> - 2024-11-26 13:22 -0600

Page 2 of 2 — ← Prev page 1 [2]

#389151

On 2024-11-27, David Brown <david.brown@hesbynett.no> wrote:
> On 26/11/2024 18:59, Kaz Kylheku wrote:
>> On 2024-11-25, Rosario19 <Ros@invalid.invalid> wrote:
>>> On Mon, 25 Nov 2024 18:23:58 -0000 (UTC), Kaz Kylheku  wrote:
>>>
>>>> void fn(int a)
>>>> {
>>>>    int x[3] = { foo(), bar(), a }; /* not in C90 */
>>>
>>> is in the above foo() called before bar()?
>> 
>> No, you cannot rely on that. Maybe it's fixed in a more recent standard,
>
> The implication of the word "fixed" is that you think the current 
> standards as somehow "broken" in this respect.  Do you think that is the 
> case?

The specification has an inconsistency, because it gives the order
in which initializations occur, yet not the order of evaluation of
the expressions that produce their values.

Above we know that x[0] is initialized first before x[1].

That doesn't even matter unless initializations are being observed,
which they can be if there is self-reference going on, like:

  int x[3] = { foo(), x[0] + bar(), x[0] + x[1] }

I'm assuming this sort of thing must to be the purpose for specifying
the order of initialization.

It looks inconsistent to me that the effects of the subobjects receiving
their inital values are ordered, but all other effects are not.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#389152

On 11/27/24 14:42, Kaz Kylheku wrote:
...
> The specification has an inconsistency, because it gives the order
> in which initializations occur, yet not the order of evaluation of
> the expressions that produce their values.

That's not an inconsistency, it's a deliberate choice to give
implementations freedom to use whichever order is most convenient.

[toc] | [prev] | [next] | [standalone]

#389153

On 2024-11-27, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> On 11/27/24 14:42, Kaz Kylheku wrote:
> ...
>> The specification has an inconsistency, because it gives the order
>> in which initializations occur, yet not the order of evaluation of
>> the expressions that produce their values.
>
> That's not an inconsistency, it's a deliberate choice to give
> implementations freedom to use whichever order is most convenient.

Implementations are not given freedom about initialization order;
in { A, B } the initialization implied by A happens before B.

Granting a freedom here while taking it away there is inconsistent.

Expression B may rely on the initialization A having completed, but 
not on the effects of A having been settled.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#389154

On 11/27/24 16:52, Kaz Kylheku wrote:
> On 2024-11-27, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> On 11/27/24 14:42, Kaz Kylheku wrote:
>> ...
>>> The specification has an inconsistency, because it gives the order
>>> in which initializations occur, yet not the order of evaluation of
>>> the expressions that produce their values.
>>
>> That's not an inconsistency, it's a deliberate choice to give
>> implementations freedom to use whichever order is most convenient.
> 
> Implementations are not given freedom about initialization order;
> in { A, B } the initialization implied by A happens before B.
> 
> Granting a freedom here while taking it away there is inconsistent.
> 
> Expression B may rely on the initialization A having completed, but 
> not on the effects of A having been settled.

I'm sorry - I thought you meant that they were logically inconsistent.
What you're actually saying is more like stylistically inconsistent.

In C90, the order in which the initializers were evaluated didn't
matter, because they were required to be static initializers. It was
only in C99 that they were allowed to be arbitrary expressions.

However, in the same version of the standard, designated initializers
were added. Designated initializers are allowed to update elements in a
different order from their order in memory, and to initialize the same
element multiple times, with only the final initialization actually
occurring. This can be convenient for setting up a rule and then adding
exceptions to that rule. If there weren't a rule mandating the order in
which initializers were applied, when two or more initializers affect
the same object, it wouldn't be possible to be certain which one
overrode the others.

[toc] | [prev] | [next] | [standalone]

#389210

On 2024-11-27, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> On 11/27/24 16:52, Kaz Kylheku wrote:
>> On 2024-11-27, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>> On 11/27/24 14:42, Kaz Kylheku wrote:
>>> ...
>>>> The specification has an inconsistency, because it gives the order
>>>> in which initializations occur, yet not the order of evaluation of
>>>> the expressions that produce their values.
>>>
>>> That's not an inconsistency, it's a deliberate choice to give
>>> implementations freedom to use whichever order is most convenient.
>> 
>> Implementations are not given freedom about initialization order;
>> in { A, B } the initialization implied by A happens before B.
>> 
>> Granting a freedom here while taking it away there is inconsistent.
>> 
>> Expression B may rely on the initialization A having completed, but 
>> not on the effects of A having been settled.
>
> I'm sorry - I thought you meant that they were logically inconsistent.
> What you're actually saying is more like stylistically inconsistent.
>
> In C90, the order in which the initializers were evaluated didn't
> matter, because they were required to be static initializers. It was
> only in C99 that they were allowed to be arbitrary expressions.
>
> However, in the same version of the standard, designated initializers
> were added. Designated initializers are allowed to update elements in a
> different order from their order in memory, and to initialize the same
> element multiple times, with only the final initialization actually
> occurring. This can be convenient for setting up a rule and then adding
> exceptions to that rule.

But it simply ends up being left to right.

Given { A, B, C }, the members are initialized in order of increasing
offset address, corresponding to left-to-right order in the syntax.

Given { [2] = A, [1] = B, [0] = C }, they are initialized in the
left-to-right order in the syntax: [2] first, then [1] then [0].

So we have order. And yet we don't have order; the expressions are not
actually sequenced.

> If there weren't a rule mandating the order in
> which initializers were applied, when two or more initializers affect
> the same object, it wouldn't be possible to be certain which one
> overrode the others.

It would make sense for that simply to be a constraint violation;
two initializations for the same object are being requested.

There is no sequencing in the initialization: { i++, i++ } would
be undefined behavior. Yet, you can request multiple initializations
of the same subobject and have it safely resolved to the rightmost?

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#389220

Kaz Kylheku <643-408-1753@kylheku.com> writes:

> On 2024-11-27, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>
>> If there weren't a rule mandating the order in which initializers
>> were applied, when two or more initializers affect the same
>> object, it wouldn't be possible to be certain which one overrode
>> the others.

That's wrong.  The priority rule for initializing the same subobject
depends not on order of evaluation but on syntactic order.  There
doesn't have to be a rule for evaluation order to make the order
of subobject overriding be well defined.

> It would make sense for that simply to be a constraint violation;
> two initializations for the same object are being requested.

It isn't that simple.  There are situations where overriding the
initialization of a particular subobject makes sense, and is
useful.  Example:

   typedef struct { int x, y; } Bas;
   typedef struct { Bas b[2]; } Foo;

   Foo
   sample_foo( Bas b ){
      Foo foo = { b, b, .b[1].y = -1 };
      return  foo;
   }

The subobject .b[1].y is overridden, but we can't take the previous
initialization of .b[1] without changing the semantics.

[toc] | [prev] | [next] | [standalone]

#389228

On 11/29/24 20:30, Kaz Kylheku wrote:
> On 2024-11-27, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
...
>> In C90, the order in which the initializers were evaluated didn't
>> matter, because they were required to be static initializers. It was
>> only in C99 that they were allowed to be arbitrary expressions.
>>
>> However, in the same version of the standard, designated initializers
>> were added. Designated initializers are allowed to update elements in a
>> different order from their order in memory, and to initialize the same
>> element multiple times, with only the final initialization actually
>> occurring. This can be convenient for setting up a rule and then adding
>> exceptions to that rule.
> 
> But it simply ends up being left to right.

Why is that it a "but"? If you want to give users control over the order
of initialization, what is simpler or more natural that using the
textual order.

> Given { A, B, C }, the members are initialized in order of increasing
> offset address, corresponding to left-to-right order in the syntax.
> 
> Given { [2] = A, [1] = B, [0] = C }, they are initialized in the
> left-to-right order in the syntax: [2] first, then [1] then [0].
> 
> So we have order. And yet we don't have order; the expressions are not
> actually sequenced.

You can always make something sound contradictory or confusing by
leaving out the details that resolve the contradiction or remove the
confusion.
Yes, the initializations of the members of an aggregate object are
ordered. And also yes, the evaluations of the initializer expressions
for those objects are unordered, the same as is generally the case -
there's only a few features of C that impose order on expressions - the
semicolon at the ends of declarations or statements are the most common.
As a general way, whenever you need to order the evaluation of
expressions that would otherwise be unordered, the way to do so is
simply put them in a different declarations or statements, which often
requires creating temperaries to hold the results of intermediate
evaluations.

>> If there weren't a rule mandating the order in
>> which initializers were applied, when two or more initializers affect
>> the same object, it wouldn't be possible to be certain which one
>> overrode the others.
> 
> It would make sense for that simply to be a constraint violation;
> two initializations for the same object are being requested.

The committee felt otherwise. The standard quite explicitly says: "...
each initializer provided for a particular subobject overriding any
previously listed initializer for the same subobject ..." (6.7.10p20). I
agree - I can see obscure situations where that rule makes the feature
more convenient. The standard also provides a relevant example where the
intended behavior depends upon this feature:

"EXAMPLE 13 Space can be "allocated" from both ends of an array by using
a single designator:
      int a[MAX] = {
            1, 3, 5, 7, 9, [MAX-5] = 8, 6, 4, 2, 0
      };

In the above, if MAX is greater than ten, there will be some zero-valued
elements in the middle; if it is less than ten, some of the values
provided by the first five initializers will be overridden by the
second five."

If you wanted the behavior to depend upon the value of MAX in precisely
the fashion provided by this feature, and this feature were not
available, the code would have to be a lot more complicated.

> There is no sequencing in the initialization: { i++, i++ } would
> be undefined behavior. Yet, you can request multiple initializations
> of the same subobject and have it safely resolved to the rightmost?

Correct. If you need initializer expressions to be ordered, you'll have
to put them in different statements or declarations.

[toc] | [prev] | [next] | [standalone]

#389163

On 27/11/2024 20:42, Kaz Kylheku wrote:
> On 2024-11-27, David Brown <david.brown@hesbynett.no> wrote:
>> On 26/11/2024 18:59, Kaz Kylheku wrote:
>>> On 2024-11-25, Rosario19 <Ros@invalid.invalid> wrote:
>>>> On Mon, 25 Nov 2024 18:23:58 -0000 (UTC), Kaz Kylheku  wrote:
>>>>
>>>>> void fn(int a)
>>>>> {
>>>>>     int x[3] = { foo(), bar(), a }; /* not in C90 */
>>>>
>>>> is in the above foo() called before bar()?
>>>
>>> No, you cannot rely on that. Maybe it's fixed in a more recent standard,
>>
>> The implication of the word "fixed" is that you think the current
>> standards as somehow "broken" in this respect.  Do you think that is the
>> case?
> 
> The specification has an inconsistency, because it gives the order
> in which initializations occur, yet not the order of evaluation of
> the expressions that produce their values.
> 
> Above we know that x[0] is initialized first before x[1].
> 
> That doesn't even matter unless initializations are being observed,
> which they can be if there is self-reference going on, like:
> 
>    int x[3] = { foo(), x[0] + bar(), x[0] + x[1] }
> 
> I'm assuming this sort of thing must to be the purpose for specifying
> the order of initialization.
> 
> It looks inconsistent to me that the effects of the subobjects receiving
> their inital values are ordered, but all other effects are not.
> 

I don't see any justification in the standard for assuming that the 
initialisers are evaluated in any particular order.  The standard (at 
least my reading of section 6.7.9) gives a clear order to the 
initialisation itself (which may, of course, be re-ordered by the 
compiler under "as-if" rules) so that if you are using designated 
initialisers, it is clear that the last initialiser for each element is 
what counts.  Not only does that section say nothing about the order of 
evaluation for the parts, it says that if an initialiser is overridden, 
then it may not be evaluated at all (with the implication being that it 
might be evaluated and the result dropped).

Section 6.7.9p23:

"""
The evaluations of the initialization list expressions are 
indeterminately sequenced with respect to one another and thus the order 
in which any side effects occur is unspecified. 152)

152) In particular, the evaluation order need not be the same as the 
order of subobject initialization.
"""


This is very much like the evaluation of arguments to a function call - 
there is no specified order or sequencing between the evaluations of the 
arguments.

[toc] | [prev] | [next] | [standalone]

#389160

Kaz Kylheku <643-408-1753@kylheku.com> writes:

> On 2024-11-25, Rosario19 <Ros@invalid.invalid> wrote:
>
>> On Mon, 25 Nov 2024 18:23:58 -0000 (UTC), Kaz Kylheku  wrote:
>>
>>> void fn(int a)
>>> {
>>>   int x[3] = { foo(), bar(), a }; /* not in C90 */
>>
>> is in the above foo() called before bar()?
>
> No, you cannot rely on that.  Maybe it's fixed in a more recent
> standard, but C99 (which I happen to have open in a PDF reader
> tab) stated that "The order in which any side effects occur among
> the initialization list expressions is unspecified.".  This
> implies that there is no sequence point between any two
> initializing expressions, which means we don't know whose
> expression's function call takes place first.

Challenge exercise for C standard enthusiasts:  It is possible
(in C99 and later) to write an initializer for x[] that puts
in the same values as the initializer above, but guarantees
foo() is called before bar().  Hint:  nothing else is needed
besides a different writing of the initializer for x[] (still
an array of length 3).  How to do it?

[toc] | [prev] | [next] | [standalone]

#389231

On Tue, 26 Nov 2024 17:59:08 -0000 (UTC), Kaz Kylheku  wrote:

>On 2024-11-25, Rosario19 <Ros@invalid.invalid> wrote:
>> On Mon, 25 Nov 2024 18:23:58 -0000 (UTC), Kaz Kylheku  wrote:
>>
>>>void fn(int a)
>>> {
>>>   int x[3] = { foo(), bar(), a }; /* not in C90 */
>>
>> is in the above foo() called before bar()?
>
>No, you cannot rely on that. Maybe it's fixed in a more recent standard,
>but C99 (which I happen to have open in a PDF reader tab) stated that 
>"The order in which any side effects occur among the initialization list
>expressions is unspecified.".  This implies that there is no sequence
>point between any two initializing expressions, which means we don't
>know whose expression's function call takes place first.
>
>In any case, a C90 compiler with the above support as an extension to
>C90 can specify rigid sequencing behavior.
>
>> void fn(int a)
>>  {
>>    int x[3];
>>    x[0]=foo(); x[1]=bar(); x[2]=a;
>>
>> this would be ok with every C compiler 
>
>One problem is, if you're doing this because your compiler is C90, you
>also have to do something about all declarations which follow the int
>x[3], since they cannot occur after a statement.  You can add another
>level of block nesting for them, or whatever.

 int fn(int a)
{ int x[3];
  int b=9;
   x[0]=foo(); x[1]=bar(); x[2]=a;
   return x[0]==0||a==b;
}

i don't see onother level of block nesting

>Initialization is preferable to leaving an object uninitialized and
>assigning. There is a scope where the name is visible, but the object
>is not initialized, inviting code to be inserted there which tries
>to use it.
>
>If I needed foo to be called before bar, I would still rather do
>the following than assignment:
>
>  int f = foo();
>  int b = bar();
>  int x[3] = { f, b, a };

ok

[toc] | [prev] | [next] | [standalone]

#389103

"Kaz Kylheku" <643-408-1753@kylheku.com> wrote in message
news:20241125101701.894@kylheku.com...
> On 2024-11-24, Paul Edwards <mutazilah@gmail.com> wrote:
> > "Janis Papanagnou" <janis_papanagnou+ng@hotmail.com> wrote in message
> > news:vhvsm9$2bmq9$1@dont-email.me...
> >> On 24.11.2024 15:00, Paul Edwards wrote:
> >> >
> >> > I have been after a public domain C compiler for decades.
> >> > [...] I'm after C90 written in C90.
> >>
> >> Why formulate the latter condition if you can bootstrap?
> >> (Did you mean; written in a "C" not more recent than C90?)
> >
> > Yes - written in C90 so that it can be maintained with
> > just knowledge of C90.
> >
> > And also written in C90 so that it is written naturally
> > for a C90 programmer, not using a subset of C90
>
> But, do yourself a favor and, have it as an extension to allow
> non-constant expressions to allow block scoped aggregates:
>
>  void fn(int a)
>  {
>    int x[3] = { foo(), bar(), a }; /* not in C90 */
>
> (You don't have to use it in the source code of the thing,
> so it can be boostrapped by other C90 compilers without
> the extension.)
>
> Also, pin down the truncation behavior of / and % to match C99.
> (Though, again, without relying on that in the C90 source
> of the compiler.)
>
> Define the behavior of a [0] array at the end of a struct,
> so that the C90 struct hack is "blessed" in your implementation.
> The C99 flexible array member cannot be used, after all.
> You can have it so that [0] has the same semantics as C99 []
> in that role.

I don't have any such code in PDOS, so it is very unlikely I
will be doing anything along those lines.

My goal is to get the existing PDOS source code to compile.
Plus the tools, including the new C compiler. So that there is
a completely public domain infrastructure that can be used as
a base to produce all of the above, and more.

If I was to enhance it to do the above to meet some market
need, it is more likely that it would be a commercial derivative
rather than being public domain.

BFN. Paul.

[toc] | [prev] | [next] | [standalone]

#389096

On 11/24/2024 8:00 AM, Paul Edwards wrote:
> Hi.
> 
> I have been after a public domain C compiler for decades.
> None of them reach C90 compliance. SubC comes the
> closest but was written without full use of C90, which
> makes it difficult to read. I'm after C90 written in C90.
> 
> A number of people have tried, but they always seem
> to fall short. One of those attempts is pdcc. The
> preprocessor was done, but the attempt (by someone
> else) to add C code generation was abandoned.
> 
> I decided to take a look at it, and it looks to me like
> a significant amount of work has already been done.
> 
> Also, my scope is limited - I am only after enough
> functionality to get my 80386 OS (PDOS) compiled,
> and I don't mind short=int=long = 32 bits, I don't
> mind not having float. I don't use bitfields.
> 
> Anyway, I have had some success in making enhancements
> to it, and here is one:
> 
> https://sourceforge.net/p/pdos/gitcode/ci/3356e623785e2c2e16c28c5bf8737e72df
> d39e04/
> 
> But I don't really know what I'm doing (I do know some
> of the theory - but this is a particular design).
> 
> E.g. now that I have managed to get a variable passed to
> a function, I now want the address of that variable passed
> to the function - ie I want to do &x instead of x - and I am
> not sure whether to create a new ADDRESS type, or
> whether it is part of VARREF or what - in the original
> (incomplete) concept. Or CC_EXPR_AMPERSAND.
> 
> I am happy to do the actual coding work - I'm just looking
> for some nudges in the right direction if anyone can assist.
> 
> Thanks. Paul.

Did you look at the Open Watcom compilers: C, C++, and F77 ?
    https://openwatcom.org/

Open Watcom has many modes of compilation: 8086, 80286, 80386, etc.

Lynn

[toc] | [prev] | [next] | [standalone]

#389097

Lynn McGuire <lynnmcguire5@gmail.com> writes:
> On 11/24/2024 8:00 AM, Paul Edwards wrote:
>> I have been after a public domain C compiler for decades.
[...]
>
> Did you look at the Open Watcom compilers: C, C++, and F77 ?
>    https://openwatcom.org/
>
> Open Watcom has many modes of compilation: 8086, 80286, 80386, etc.

Open Watcom's compilers are not public domain, so they don't meet Paul's
(rather odd) requirements.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#389099

On 11/25/2024 4:10 PM, Keith Thompson wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>> On 11/24/2024 8:00 AM, Paul Edwards wrote:
>>> I have been after a public domain C compiler for decades.
> [...]
>>
>> Did you look at the Open Watcom compilers: C, C++, and F77 ?
>>     https://openwatcom.org/
>>
>> Open Watcom has many modes of compilation: 8086, 80286, 80386, etc.
> 
> Open Watcom's compilers are not public domain, so they don't meet Paul's
> (rather odd) requirements.

Are you sure about the public domain thing ?  The license is here:
    http://openwatcom.org/ftp/install/license.txt

I forgot to mention that the Open Watcom compilers are released for the 
following platforms: DOS, Linux, OS/2, and Win32.  A Win64 fork and port 
is being worked on at:
    https://open-watcom.github.io/

Lynn

[toc] | [prev] | [next] | [standalone]

#389100

Lynn McGuire <lynnmcguire5@gmail.com> writes:
> On 11/25/2024 4:10 PM, Keith Thompson wrote:
>> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>>> On 11/24/2024 8:00 AM, Paul Edwards wrote:
>>>> I have been after a public domain C compiler for decades.
>> [...]
>>> Did you look at the Open Watcom compilers: C, C++, and F77 ?
>>>     https://openwatcom.org/
>>>
>>> Open Watcom has many modes of compilation: 8086, 80286, 80386, etc.
>> Open Watcom's compilers are not public domain, so they don't meet
>> Paul's (rather odd) requirements.
>
> Are you sure about the public domain thing ?  The license is here:
>    http://openwatcom.org/ftp/install/license.txt

Yes, I'm sure that that's a license that imposes some restrictions.
It's not public domain.

Just one example:

"""
You must retain and reproduce in all copies of Original Code the copyright
and other proprietary notices and disclaimers of Sybase as they appear in the
Original Code, and keep intact all notices in the Original Code that refer to
this License;
"""

Anything that's public domain has no copyright.

Why do you ask?

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#389109

On 11/25/2024 6:49 PM, Keith Thompson wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>> On 11/25/2024 4:10 PM, Keith Thompson wrote:
>>> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>>>> On 11/24/2024 8:00 AM, Paul Edwards wrote:
>>>>> I have been after a public domain C compiler for decades.
>>> [...]
>>>> Did you look at the Open Watcom compilers: C, C++, and F77 ?
>>>>      https://openwatcom.org/
>>>>
>>>> Open Watcom has many modes of compilation: 8086, 80286, 80386, etc.
>>> Open Watcom's compilers are not public domain, so they don't meet
>>> Paul's (rather odd) requirements.
>>
>> Are you sure about the public domain thing ?  The license is here:
>>     http://openwatcom.org/ftp/install/license.txt
> 
> Yes, I'm sure that that's a license that imposes some restrictions.
> It's not public domain.
> 

Skims license...

Yeah, I wouldn't touch that one with a stick...


> Just one example:
> 
> """
> You must retain and reproduce in all copies of Original Code the copyright
> and other proprietary notices and disclaimers of Sybase as they appear in the
> Original Code, and keep intact all notices in the Original Code that refer to
> this License;
> """
> 
> Anything that's public domain has no copyright.
> 

This is one of the "less bad" restrictions in there (it is merely, what 
most other licenses require).

It isn't really a FOSS license at all.



> Why do you ask?
> 
> [...]
> 


Looking around, it seems my idea for a "MIT Minus" license already 
exists in two different variants:
   MIT No Attribution
   BSD Zero Clause

Which do basically let people do whatever with the code, while still 
providing the protection of a no warranty clause.


I guess it is possible I could consider moving to "MIT No Attribution" 
for some of my stuff if the normal MIT (Expat) license is seen as asking 
too much.

But, possibly, oh the terror, some of my past projects had used the LGPL...


My projects still do bundle some GPL code, but it is "OK" as I don't use 
any of the GPL code in the non GPL parts of the project (it mostly 
applies to things like the Doom and Quake engines and similar).

Though, they are lacking the WAD and PAK files, as redistributing them 
is questionable. In theory, the Shareware files could be distributed in 
an unmodified form, but safer is to omit them.


For my own uses, I was largely using WAD files that were converted to 
WAD2 mostly so that they could use data compression (mostly LZ4 and/or 
RP2 in this case; packing tool using whichever gave a smaller file). 
Functionally, this doesn't change much, but is mostly to make loading 
times faster (as with program loading, loading in Doom is often IO bound).

Though, Doom does spend a long time doing texture loading during startup 
with a primarily CPU bound task. Namely, in the WAD file, textures exist 
as "patch" lumps, and at load time the Doom engine glues them together 
to build the final wall textures. Not an obvious way to speed it up, can 
note that id's original response was to display some square brackets and 
fill it in with a series of dots (eg: "[.......       ]").

The engines retain the ability to load the original IWAD format as well.


Quake didn't originally use or support WAD2 with compressed lumps, but 
it was provided for in the format. Originally, it specified uncompressed 
lumps and LZSS (IIRC). I used LZ4 and RP2 instead, as they are both 
faster and compress better than LZSS (but, back in the 90s, LZSS was 
fairly popular; taking on a lot of the roles one might now find LZ4 or 
similar taking on).

Some of this stuff could have theoretically been avoided with filesystem 
level compression, but this isn't really a thing in FAT32.


Sadly, there is no Wolf3D port, as while I had partially ported Wolf3D, 
what was lacking was a version of the Wolf3D engine under friendly 
license terms. I did experimentally also recreate Wolf3D in my modified 
port of the ROTT engine (also GPL), but couldn't distribute it with data 
files as, again, I can't legally distribute these (and the original DOS 
files wont work, things would need to be regenerated using the data 
files from the Wold3D iOS port, which while available were also not 
under friendly license terms).

Did partially make a set of "placeholder" assets partly derived from 
parts scavenged from FreeDoom, but it is pretty far from recapturing the 
Wolf3D experience (and, likely, someone would also need to make a 
"legally distinct" stand-in for the Wolf3D levels).

Potentially, I could make a tool to allow expressing maps as ASCII text 
files, likely as 64x64 grids of characters, with data encoded in the 
characters. Simple case might be to use a single grid of characters with 
a translation key (Wolf3D had used 3 planes internally, but a lot of 
cases are mutually exclusive, like one isn't generally going to be 
putting entities inside walls, ...).

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web