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

Groups > alt.os.development > #8251 > unrolled thread

Re: What form of executable or load module for your OS?

Back to article view | Back to alt.os.development

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: What form of executable or load module for your OS? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-06-25 21:20 -0700
    Re: What form of executable or load module for your OS? "James Harris" <james.harris.1@gmail.com> - 2015-07-01 10:36 +0100
      Re: What form of executable or load module for your OS? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-01 21:07 -0700
        Re: What form of executable or load module for your OS? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-02 23:35 -0700
          Re: What form of executable or load module for your OS? "James Harris" <james.harris.1@gmail.com> - 2015-07-03 08:35 +0100
            Re: What form of executable or load module for your OS? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-03 02:49 -0700
              Re: What form of executable or load module for your OS? "James Harris" <james.harris.1@gmail.com> - 2015-07-03 11:27 +0100
                Re: What form of executable or load module for your OS? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-03 16:54 -0400
                  Re: What form of executable or load module for your OS? "James Harris" <james.harris.1@gmail.com> - 2015-07-03 22:45 +0100
                    Re: What form of executable or load module for your OS? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-03 17:56 -0400
                    Re: What form of executable or load module for your OS? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-03 15:28 -0700
                      Re: What form of executable or load module for your OS? "James Harris" <james.harris.1@gmail.com> - 2015-07-03 23:48 +0100
                        Re: What form of executable or load module for your OS? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-03 21:52 -0700
                        Re: What form of executable or load module for your OS? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-04 04:00 -0400
                          Re: What form of executable or load module for your OS? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-04 04:42 -0700
                            Re: What form of executable or load module for your OS? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-05 02:12 -0400
                              Re: What form of executable or load module for your OS? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-05 00:47 -0700
                                Re: What form of executable or load module for your OS? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-05 05:28 -0400
                                  Re: What form of executable or load module for your OS? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-05 02:58 -0700
                            Re: What form of executable or load module for your OS? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-06 06:21 -0400
                              Re: What form of executable or load module for your OS? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-07 01:44 -0700
                                Re: What form of executable or load module for your OS? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-07 05:40 -0400
                                  Re: What form of executable or load module for your OS? "Kerr Mudd-John" <admin@127.0.0.1> - 2015-07-07 14:02 +0100
                                    Re: What form of executable or load module for your OS? "wolfgang kern" <nowhere@never.at> - 2015-07-07 18:13 +0200
                                      Re: What form of executable or load module for your OS? "Kerr Mudd-John" <notsaying@invalid.org> - 2015-07-08 12:54 -0100
                                        Re: What form of executable or load module for your OS? "James Harris" <james.harris.1@gmail.com> - 2015-07-09 13:19 +0100
                                  Re: What form of executable or load module for your OS? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-07 22:10 -0700
                                    Re: What form of executable or load module for your OS? "James Harris" <james.harris.1@gmail.com> - 2015-07-08 08:48 +0100
                                      Re: What form of executable or load module for your OS? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-08 23:53 -0700
                                      Re: What form of executable or load module for your OS? "James Harris" <james.harris.1@gmail.com> - 2015-07-09 17:29 +0100
                                        Re: What form of executable or load module for your OS? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-10 01:01 -0700
                                          Re: What form of executable or load module for your OS? "James Harris" <james.harris.1@gmail.com> - 2015-07-10 13:46 +0100
                                      Re: What form of executable or load module for your OS? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-10 00:59 -0700
                                    Re: What form of executable or load module for your OS? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-08 03:52 -0400
                                      Re: What form of executable or load module for your OS? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-08 06:46 -0700
                                      Re: What form of executable or load module for your OS? "James Harris" <james.harris.1@gmail.com> - 2015-07-09 13:16 +0100
                                      Re: What form of executable or load module for your OS? "s_dubrovich@yahoo.com" <s_dubrovich@yahoo.com> - 2015-07-11 09:57 -0700
                                        Re: What form of executable or load module for your OS? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-13 02:47 -0400
                                          Re: What form of executable or load module for your OS? "s_dubrovich@yahoo.com" <s_dubrovich@yahoo.com> - 2015-07-14 07:39 -0700
                                            Re: What form of executable or load module for your OS? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-15 02:37 -0400
          Code insanity "Mike Gonta" <mikegonta@gmail.com> - 2015-07-03 03:47 -0400
            Re: Code insanity "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-03 02:57 -0700
            Re: Code insanity (was: What form of executable or load module for your OS?) "James Harris" <james.harris.1@gmail.com> - 2015-07-03 11:35 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#8310

On Monday, July 6, 2015 at 3:20:58 AM UTC-7, Rod Pemberton wrote:
> On Sun, 05 Jul 2015 18:15:50 -0400, Alexei A. Frounze  
> <...@gmail.com> wrote:
> 
> > For MOVZX. PUSHF/POPF not needed.
> >
> > MOVSX is worse:
> >
> > PUSH AX ; if dst != AX
> > MOV AL, src
> > CBW
> > MOV dst, AX ; if dst != AX
> > POP AX ; if dst != AX
> >
> 
> It's too bad there is no PUSH reg8 ...
> 
> > There are two types of comparisons in Smaller C:
> > 1. comparisons whose result is used for if/while/for:
> >   if (a < b) ...
> >   while (a < b) ...
> >   do ... while (a < b);
> >   for (...; a < b; ...) ...
> > 2. all other comparisons:
> >   c = a < b;
> > CMP+Jcc are used in the former.
> > CMP+SETcc are used in the latter.
> 
> If those are the only comparisons, what are you using MOVSX for?

Loads from memory of signed chars and signed shorts, sign extensions
after ++, --, =, +=, etc, which are performed on lvalues that are
signed chars/shorts.

> Signed-arithmetic?

All char and short operands are implicitly converted to [unsigned] int,
all arithmetic is then done on machine words, signed or unsigned and the
result is of the same [unsigned] int type. That by itself simplifies
things a great deal. I only need to sign/zero-extend on loads and stores
without needing any special cases in the middle.

> If so, delay using CBW until an arithmetic
> operation is performed when AX is free.  Then, no need for MOVSX.

I have to remind you again that the compiler is not an optimizing
one and even some trivial stuff is not optimized so as not to
(over)complicate or enlarge its code.

I think you still don't realize the simple idea of a simple
compiler as also evidenced by the earlier statement that the
generation of jcc's is somehow wrong (and NASM being wrong as well,
is there anything right?:). It's all by design, by a simple design.

Alex

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

#8311

On Tue, 07 Jul 2015 04:44:33 -0400, Alexei A. Frounze  
<alexfrunews@gmail.com> wrote:

> I have to remind you again that the compiler is not an optimizing
> one and even some trivial stuff is not optimized so as not to
> (over)complicate or enlarge its code.

The issue at this point was getting working 8086 for James.
Emitting 8086 is going to complicate things slightly.  Of
course, I had assumed James already did some testing with
NASM for x86, which was why he was taking issue with SmallerC,
but apparently that wasn't the situation.

> I think you still don't realize the simple idea of a simple
> compiler as also evidenced by the earlier statement that the
> generation of jcc's is somehow wrong

It is.

> (and NASM being wrong as well,

It is.

As you noted, 0.98.39 is not perfect either, but at one point
in time it was much better than other assemblers.  Now?  You
might as well use MASM ...  NASM is doing the same things as
MASM does.   I'll blame H.P.A. for that, since he introduced
a bunch of that crud for 64-bit mode.

> It's all by design, by a simple design.

It's interesting that when I mention "simpler" designs and
method of implementations both here and elsewhere, e.g.,
comp.lang.asm.x86, comp.lang.misc, alt.lang.asm, etc that
everyone rejects my "simpler" design, which is provably so.

So, why should you be any different? ...  ;-)


Also, are you using SETcc for any condition other
than CF=1 as SETC?  E.g., do you use SETZ, SETS,
SETP, SETO, etc?

I'm assuming you're using SETG, SETGE, SETL, SETLE,
SETA, SETAE, SETB, SETBE, for signed and unsigned
integer comparisons.

However, use of the CF from comparison may be generating
SETC in general code.  For 8086, SETcc could be eliminated
for the SETC case without using Jcc:

SALC ; 0x00 for CF=0 or 0xFF for CF=1
CBW  ; optionally, extend to 0 or -1 as 16-bit

It does use SALC, which is officially "undocumented" but
well known and widely used.  If 16-bit extension isn't
needed, then SALC will do, optionally AND 01h to match
0 or 1 from SETC.  Although, you may prefer SALC CBW for
16-bit logical operations from bitwise instructions for
8086.


Rod Pemberton

-- 
Tolerance and socialism attracts intolerance and terrorism.  See:
France, United Kingdom, Germany, Denmark, Belgium, Netherlands, ...
UK: Strong encryption, non-issue. GR: Eurozone currency, priority.

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

#8312

On Tue, 07 Jul 2015 10:40:17 +0100, Rod Pemberton <boo@fasdfrewar.cdm>  
wrote:

> On Tue, 07 Jul 2015 04:44:33 -0400, Alexei A. Frounze  
> <alexfrunews@gmail.com> wrote:
>
>> I have to remind you again that the compiler is not an optimizing
>> one and even some trivial stuff is not optimized so as not to
>> (over)complicate or enlarge its code.
>
> The issue at this point was getting working 8086 for James.
> Emitting 8086 is going to complicate things slightly.  Of
> course, I had assumed James already did some testing with
> NASM for x86, which was why he was taking issue with SmallerC,
> but apparently that wasn't the situation.
>
>> I think you still don't realize the simple idea of a simple
>> compiler as also evidenced by the earlier statement that the
>> generation of jcc's is somehow wrong
>
> It is.
>
>> (and NASM being wrong as well,
>
> It is.
>
> As you noted, 0.98.39 is not perfect either, but at one point
> in time it was much better than other assemblers.  Now?  You
> might as well use MASM ...  NASM is doing the same things as
> MASM does.   I'll blame H.P.A. for that, since he introduced
> a bunch of that crud for 64-bit mode.
>
>> It's all by design, by a simple design.
>
> It's interesting that when I mention "simpler" designs and
> method of implementations both here and elsewhere, e.g.,
> comp.lang.asm.x86, comp.lang.misc, alt.lang.asm, etc that
> everyone rejects my "simpler" design, which is provably so.
>
> So, why should you be any different? ...  ;-)
>
>
> Also, are you using SETcc for any condition other
> than CF=1 as SETC?  E.g., do you use SETZ, SETS,
> SETP, SETO, etc?
>
> I'm assuming you're using SETG, SETGE, SETL, SETLE,
> SETA, SETAE, SETB, SETBE, for signed and unsigned
> integer comparisons.
>
> However, use of the CF from comparison may be generating
> SETC in general code.  For 8086, SETcc could be eliminated
> for the SETC case without using Jcc:
>
> SALC ; 0x00 for CF=0 or 0xFF for CF=1
> CBW  ; optionally, extend to 0 or -1 as 16-bit
>
> It does use SALC, which is officially "undocumented" but

isn't SALC just
SBC al,al
anyway?

> well known and widely used.  If 16-bit extension isn't
> needed, then SALC will do, optionally AND 01h to match
> 0 or 1 from SETC.  Although, you may prefer SALC CBW for
> 16-bit logical operations from bitwise instructions for
> 8086.
>
>
> Rod Pemberton
>


-- 
Bah, and indeed, Humbug

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

#8313

Kerr Mudd-John asked: 
...

>> It does use SALC, which is officially "undocumented" but
 
> isn't SALC just SBC al,al anyway?
 
SBC ? 
YES. x86's SBB AL,AL and SALC work as: 
SUB AL,AL (produce a Zero followed by SUB AL,Cy) and the 
Carry came from any previous instruction.

SALC seem to be a side-effect (not designed) single byte shortcut.  

64-bit AMD wont support it anymore and Intel x86-64 may reuse this 
opcode byte for a new prefix-variant anyway.
__
wolfgang

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

#8317

On Tue, 07 Jul 2015 15:13:00 -0100, wolfgang kern <nowhere@never.at> wrote:

>
> Kerr Mudd-John asked: ...
>
>>> It does use SALC, which is officially "undocumented" but
>
>> isn't SALC just SBC al,al anyway?
>  SBC ? YES. x86's SBB AL,AL and SALC work as: SUB AL,AL (produce a Zero  
> followed by SUB AL,Cy) and the Carry came from any previous instruction.
>
sorry, SBB. if I'm thinking about Carry, I think ADC so SBC as the  
opposite!

> SALC seem to be a side-effect (not designed) single byte shortcut.   
> 64-bit AMD wont support it anymore and Intel x86-64 may reuse this  
> opcode byte for a new prefix-variant anyway.

So it might be prudent to not save the 1 byte but instead code SBB AL,AL  
instead of SALC.

> __
> wolfgang
>


-- 
Bah, and indeed, Humbug

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

#8323

"Kerr Mudd-John" <notsaying@invalid.org> wrote in message 
news:op.x1gjliw3xefm1i@anyhost.anywhere...
> On Tue, 07 Jul 2015 15:13:00 -0100, wolfgang kern <nowhere@never.at> 
> wrote:

...

>> SALC seem to be a side-effect (not designed) single byte shortcut. 
>> 64-bit AMD wont support it anymore and Intel x86-64 may reuse this 
>> opcode byte for a new prefix-variant anyway.
>
> So it might be prudent to not save the 1 byte but instead code SBB 
> AL,AL  instead of SALC.

There is a small difference in that, AIUI, SALC left flags unchanged.

Other than that, SBB is more useful in that it can be applied to any 8- 
or 16-bit register.

James

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

#8314

On Tuesday, July 7, 2015 at 2:40:05 AM UTC-7, Rod Pemberton wrote:
> On Tue, 07 Jul 2015 04:44:33 -0400, Alexei A. Frounze  
> <...@gmail.com> wrote:
> 
> > I have to remind you again that the compiler is not an optimizing
> > one and even some trivial stuff is not optimized so as not to
> > (over)complicate or enlarge its code.
> 
> The issue at this point was getting working 8086 for James.

I'm a bit unsure here. He seems to be using bcc(?) for 16-bit code.
Perhaps, James should clarify whether or not he has tried or is
trying to make Smaller C emit 8086 code or at least is interested
in such a capability in Smaller C.

> Emitting 8086 is going to complicate things slightly.  Of
> course, I had assumed James already did some testing with
> NASM for x86, which was why he was taking issue with SmallerC,
> but apparently that wasn't the situation.
> 
> > I think you still don't realize the simple idea of a simple
> > compiler as also evidenced by the earlier statement that the
> > generation of jcc's is somehow wrong
> 
> It is.
> 
> > (and NASM being wrong as well,
> 
> It is.

AFAIK, you have provided nothing of substance to support the above
claims, merely fears of the kind "oh, no, NASM's doing something
behind my back, it can't be good, and Smaller C is supportive of
that sin, run!".

> As you noted, 0.98.39 is not perfect either, but at one point
> in time it was much better than other assemblers.  Now?  You
> might as well use MASM ... 

MASM? You're talking nonsense.

> NASM is doing the same things as
> MASM does.   I'll blame H.P.A. for that, since he introduced
> a bunch of that crud for 64-bit mode.

Sure, take it up with him, if you're in an especially blameful mood.
Other than the size of nasm.exe and its performance on thousands of
branches, I'm pretty happy with NASM.

> > It's all by design, by a simple design.
> 
> It's interesting that when I mention "simpler" designs and
> method of implementations both here and elsewhere, e.g.,
> comp.lang.asm.x86, comp.lang.misc, alt.lang.asm, etc that
> everyone rejects my "simpler" design, which is provably so.

I don't recall of a design of yours of a C compiler simpler
and smaller than Smaller C and yet having all of its
functionality and supporting at least the same architectures
and platforms.

I doubt there is one. If there is, I'm all ears. If there isn't,
the above talk about so-provable simpler designs is just an
irrelevant (in the context of Smaller C) blabber.

So, is there?

Some of your suggested code improvements are impractical, because
you either ignore the context or aren't sufficiently versed in it.
AFAIK, to date you still haven't used Smaller C beyond just one
short stint and I'm certain you have spent even less time
reading and understanding its code/design.
Doesn't it feel good to be generous, Rod, when you give something
to others? Well, sorry, impractical suggestions are of little value
to the recipients.

> So, why should you be any different? ...  ;-)

You mean, why shouldn't I reject your simpler designs just as well?
Or you mean, why shouldn't I be another Rod?

> Also, are you using SETcc for any condition other
> than CF=1 as SETC?  E.g., do you use SETZ, SETS,
> SETP, SETO, etc?

Naturally, yes.

> I'm assuming you're using SETG, SETGE, SETL, SETLE,
> SETA, SETAE, SETB, SETBE, for signed and unsigned
> integer comparisons.
> 
> However, use of the CF from comparison may be generating
> SETC in general code.  For 8086, SETcc could be eliminated
> for the SETC case without using Jcc:
> 
> SALC ; 0x00 for CF=0 or 0xFF for CF=1
> CBW  ; optionally, extend to 0 or -1 as 16-bit
> 
> It does use SALC, which is officially "undocumented" but
> well known and widely used.  If 16-bit extension isn't
> needed, then SALC will do, optionally AND 01h to match
> 0 or 1 from SETC.  Although, you may prefer SALC CBW for
> 16-bit logical operations from bitwise instructions for
> 8086.

I have to remind you yet again that special casing is useful
but complicates and inflates code, which is something I prefer
to avoid in Smaller C.

Alex

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

#8315

"Alexei A. Frounze" <alexfrunews@gmail.com> wrote in message 
news:5b4a052e-4e93-4737-9e64-acbdc6ffc184@googlegroups.com...
> On Tuesday, July 7, 2015 at 2:40:05 AM UTC-7, Rod Pemberton wrote:

...

>> The issue at this point was getting working 8086 for James.
>
> I'm a bit unsure here. He seems to be using bcc(?) for 16-bit code.
> Perhaps, James should clarify whether or not he has tried or is
> trying to make Smaller C emit 8086 code or at least is interested
> in such a capability in Smaller C.

I'll explain.

I currently use Bruce's bcc. It is the only compiler I have found that 
runs on Linux and generates 8086 code. I have been told that it is 
possible to run DOS compilers under Linux by running them inside DosBox. 
That's something I may come back to, if necessary, but having spent 
considerable time trying DOS compilers I am not sure that there is one 
better than bcc.

That said, I keep the C code portable so while I use bcc I am not tied 
to bcc or any other compiler. If I fould a suitable replacement for bcc 
I should be able to switch to it fairly easily.

Unfortunately bcc has a bug in its structure-passing code. I have looked 
at the compiler's source but not understood it enough to see how to fix 
the bug, and the source appears not to be maintained. I am working round 
the bug but it can be a nuisance.

I looked at getting Smaller C to generate 8086 code. Complements to the 
chef in that, while I didn't follow it all, the x86 code gen I looked at 
was much easier to understand than I expected and much easier than other 
code I have read.

I think it would be hard for me to modify, though, for two reasons: 1. 
there seems to be quite a lot of it (i.e. of x86-specific codegen code) 
and 2. some parts of it that I would need use 32-bit registers.

Adding a completely new codegen target (i.e. 8086) might be possible but 
a lot of it would overlap with the existing x86_16/32 output. That, 
therefore, doesn't seem to be a good way to go.

So I wondered about writing a Smaller C codegen module that would output 
an intermediate representation, and then doing final code gen from the 
IR. With a bit of work on the IR form that seems to be feasible and 
could allow 32-bit ops to be handled relatively easily. It might even, 
if Smaller C supports it, allow 64-bit ops to be handled in 16-bit mode. 
I am thinking that the IR would say to the code generator "subtract 
these two 32-bit numbers" and similar and it would be up to the 8086 
code generator to do the 32-bit arithmetic on 16-bit quantities but 
achieve the same result.

Of course, it's not quite that simple. The IR would have to tell the 
code gen things like when an operation is expected to set flags for 
later comparisons and the IR would probably have lots of temporaries so 
there would need to be some register allocation done later after the 
assembly has been generated.

I did even take a look to see if I could find some existing programs 
which would do things like 8086 register allocation on asm output but 
didn't find any.

All of this would take time I cannot spend just now. I have an imperfect 
but working solution with bcc and will have to continue to use it for a 
while. It is notable, however, that the considered 8086 register 
allocation, the 8086 code gen and parts of the IR are very modular. If I 
spent time on them I might be able to reuse them in other projects, and 
I would try to minimise the 8086-specific parts so the rest of it could 
be used on different architectures. But that's for the future.

That's a long answer to the things you asked but hopefully it explains 
where I am coming at this from.

James

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

#8321

On Wednesday, July 8, 2015 at 10:20:21 PM UTC-7, Alexei A. Frounze wrote:
...
> I have probably already mentioned it, the existing "IR" is basically
> an RPN representation of a C expression, which is naturally suited
> for on-stack evaluation (e.g. push a, push b, add the two, replace them
> with their sum on the stack), but which can also be trivially transformed
> into a tree with nodes having links to their parents and children.

Oh, and the top of the stack on x86 is (E)AX. This makes "return expr;"
as trivial as code for "expr" followed by a jump to the function epilogue.
(E)BX, (E)CX and (E)DX are just temporary registers that aren't anyhow
related to the stack of values and are simply used as temporaries for
things like memory reads/writes, shift counts, division remainders.

Alex

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

#8325

"James Harris" <james.harris.1@gmail.com> wrote in message 
news:mnls5i$rjl$1@dont-email.me...

Noticed some typos in the previous post. This is to correct them.

...

>  mov r0, [x]
>  sub r0, 1

There would be a call to alter() in here, the specifics to suit a 
particular calling convention.

  mov r0, 'retval' (omitted if return val reg can be used)
>  cmp r0, [y]    jna

...

> That is intended to simplify part of the compile process and make it 
> easier to add a new code-get target.

"code-get" should have been "code-gen"

...

> The things you have included or considered, like an IR and matching 
> multiple operations into one target instruction, are more advanced 
> that I expected for what you deprecatingly call a simple compiler.

"that" should have been "then"

James

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

#8331

On Thursday, July 9, 2015 at 9:29:48 AM UTC-7, James Harris wrote:
...
> > The things you have included or considered, like an IR and matching 
> > multiple operations into one target instruction, are more advanced 
> > that I expected for what you deprecatingly call a simple compiler.
> 
> "that" should have been "then"

Nope. Try again. :)

Alex

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

#8335

"Alexei A. Frounze" <alexfrunews@gmail.com> wrote in message 
news:9cb3bb8f-9f83-496a-9961-9237fded3c08@googlegroups.com...
> On Thursday, July 9, 2015 at 9:29:48 AM UTC-7, James Harris wrote:
> ...
>> > The things you have included or considered, like an IR and matching
>> > multiple operations into one target instruction, are more advanced
>> > that I expected for what you deprecatingly call a simple compiler.
>>
>> "that" should have been "then"
>
> Nope. Try again. :)

Aargh, yes, you are right. Rather than correct them myself I'll have to 
leave you to interpret my typos in future. You do a better job of it!

James

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

#8330

On Thursday, July 9, 2015 at 6:16:57 AM UTC-7, James Harris wrote:
> "Alexei A. Frounze" <...@gmail.com> wrote in message 
> news:69e087b5-cb4e-4938-a3de-2744dfe3d794@googlegroups.com...
> > On Wednesday, July 8, 2015 at 12:48:17 AM UTC-7, James Harris wrote:
> >> "Alexei A. Frounze" <...@gmail.com> wrote in message
> >> news:5b4a052e-4e93-4737-9e64-acbdc6ffc184@googlegroups.com...
> >> > On Tuesday, July 7, 2015 at 2:40:05 AM UTC-7, Rod Pemberton wrote:
> 
> ...
> 
> >> So I wondered about writing a Smaller C codegen module that would 
> >> output
> >> an intermediate representation,
> >
> > There's one already. It's what the x86 and MIPS code generators
> > get as input.
> 
> OK.
> 
> >> and then doing final code gen from the
> >> IR. With a bit of work on the IR form that seems to be feasible and
> >> could allow 32-bit ops to be handled relatively easily. It might 
> >> even,
> >> if Smaller C supports it, allow 64-bit ops to be handled in 16-bit 
> >> mode.
> >
> > Native 64-bit support doesn't fit well into the model, where 
> > everything
> > is at most a machine word in size (with int/machine word being 16-bit 
> > or
> > 32-bit only).
> 
> Will make some comments on that below.
> 
> >> I am thinking that the IR would say to the code generator "subtract
> >> these two 32-bit numbers" and similar and it would be up to the 8086
> >> code generator to do the 32-bit arithmetic on 16-bit quantities but
> >> achieve the same result.
> >>
> >> Of course, it's not quite that simple. The IR would have to tell the
> >> code gen things like when an operation is expected to set flags for
> >> later comparisons and the IR would probably have lots of temporaries 
> >> so
> >> there would need to be some register allocation done later after the
> >> assembly has been generated.
> >
> > I have probably already mentioned it, the existing "IR" is basically
> > an RPN representation of a C expression, which is naturally suited
> > for on-stack evaluation (e.g. push a, push b, add the two, replace 
> > them
> > with their sum on the stack), but which can also be trivially 
> > transformed
> > into a tree with nodes having links to their parents and children.
> 
> What I had in mind was a more abstract model, using register-transfer 
> instructions (which would include three-address code for some, but not 
> all, of it). For example, consider source with this expression (which 
> was chosen to include arithmetic, function call, and comparison 
> operations):
> 
>   if (alter(x - 1) > y)
> 
> Say alter() had been declared as
> 
>   unsigned alter(unsigned)
> 
> And say x and y were both unsigned so that all integers and 
> subexpressions were as wide as a register. The IR woud tell the code 
> generator to translate the following.
> 
>   t1 <= x - 1
>   t2 <= alter(t1)
>   if (t2 > y)
> 
> In reality the data sizes and types would be included but I have omitted 
> them for clarity and as they are all the same size and type. With them 
> included the same IR code would appear as
> 
>   (unsigned) t1 <= (unsigned) x - (unsigned) 1
>   (unsigned) t2 <= alter((unsigned) t1)
>   if ((unsigned) t1 > (unsigned) t2)
> 
> The code generator could then implement that in terms of the size of 
> unsigned values, i.e. register-sized words, something like
> 
>   mov r0, [x]
>   sub r0, 1
>   cmp r0, [y]
>   jna
> 
> In that, r0 is a placeholder. The actual register would be filled in 
> later and could be, for example, AX or EAX or RAX.

The 3-address code itself is OK. You can derive it from what I have
now.

However, since the compiler buffers nearly nothing (except declaration
info) and invokes the code generator as soon as possible (to emit data
or generate and emit code) and at any moment can emit code/data from
an inline asm("") statement, optimizations on this 3-address code will
be limited by the available scope (one full expression at the moment,
possibly several if uninterrupted by asm(""), goto labels, etc). And
there's no information about volatiles preserved, so, you're limited
in what you can safely do in terms of optimizations. JFYI.

> But say alter() had been declared as
> 
>   ui64 alter(ui64)
> 
> where ui64 means unsigned int 64. To make it a bit more interesting 
> let's also say that x and y were 32-bit. I would expect the IR to 'say' 
> to the code generator as follows.
> 
>   (ui32) t1 <= (ui32) x - (ui32) 1
>   (ui64) t2 <= (ui32) t1  //widen the (x - 1) value
>   (ui64) t3 <= alter((ui64) t2)  //in and out are both 64-bit
>   (ui64) t4 <= (ui32) y //widen y
>   if ((ui64) t3 > (ui64) t4)
> 
> The idea is that each of the code generators would be responsible for 
> translating that sequence, whether the code gen target was 8086, ARM32 
> or AMD64. (That includes the function call to alter() wherein passing 
> and returning the 64-bit value would be handled similarly to passing and 
> returning a struct.

You can pack however many things you like into a struct right now and
pass it by value (implemented inefficiently, but correctly, AFAIK).
The problem with 64-bit ints is that in order to support them I need to
support them not only in the code generator, but elsewhere, but elsewhere
the largest integer type used is [unsigned] int. My list of things to
support 32-bit longs in 16-bit mode(l)s (tiny/small) goes something like:
  - parse 32-bit constants and the L suffix
  - parse declarations with long
  - sizeof/decl size/alignment size
  - promote to long
  - cast to/from long
  - truncate 16-bit and 32-bit constants properly
  - division/shift overflow checks
  - 16/32-bit comparison
  - type/compat checks
  - size of fxn params
  - statements: if/for/while/switch to support 16-bit and 32-bit ints
  - fxn returning 16-bit and 32-bit ints
  - 16-bit and 32-bit param passing
  - ...
These are the same things needed in order to support 64-bit ints in
32-bit mode.

> Note that what the IR instructions that get passed to the code gen would 
> be the same irrespective of the width of the code gen's registers. It 
> would be up to the code gen program to convert it for the specific 
> target architecture.

Yep, as is done right now.

> That is intended to simplify part of the compile process and make it 
> easier to add a new code-get target.

I'm not sure about it. Typically, the problem of adding a new target
architecture is in the differences between it and the existing ones.
Generic code won't help here, unless it's a pretty advanced piece of
code that can be configured and tuned for pretty much any architecture/ instruction set in existence. There's almost always an instruction
to add two registers or a register and an integer constant. But
memory addressing, calling conventions, comparing/branching instructions,
sign/zero-extension, implicit register operands in some/many instructions,
all that makes adding another target painful.

> There is more to it but can you see what I had in mind and how that 
> would allow even a 16-bit CPU to work with 32-bit and 64-bit integers 
> without using anything more than its inbuilt 16-bit registers?

You didn't consider the limitations outside the code generator, as
I outlined above.

> ...
> 
> > I should probably write a guide to porting Smaller C to other
> > architectures.
> 
> To be realistic, for much of what we write few other people will join in 
> to make anything we want to merge back but it's not a bad idea to write 
> a guide to fellow programmers, if you want them to work on your code.
> 
> You mention porting it. I presume you mean adding translation targets. 

Exactly that, yes.

> IMO, ideally, C code wouldn't need to be ported. If written to be 
> portable it should just compile on different architectures. No porting 
> required.

I think, the compiler's code itself is sufficiently portable right now.
It compiles correctly with at least 5 different compilers (including
itself) and for at least two different architectures.

> ...
> 
> > As you can see, there isn't anything extraordinary here. You have a
> > traditional tree-like IR for every expression that needs to be emitted
> > as code and that's what you'll find in intro books on compilers.
> > You can swap the left and the right children, you can change, insert 
> > or
> > remove operators and operands. You can match certain patterns with
> > more efficient instructions (e.g. "foo 1 + read4" could be done as
> > "mov eax, [foo + 1]" instead of "mov eax, foo" + "add eax, 1"/"inc 
> > eax" +
> > "mov eax, [eax]").
> 
> The things you have included or considered, like an IR and matching 
> multiple operations into one target instruction, are more advanced that 
> I expected for what you deprecatingly call a simple compiler.

Perhaps, having now seen the list of things needed to be done to support
double machine word integer types you reconsider calling it advanced
even if/when it manages to do the simple kind of matching as just
suggested. :)

Alex

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

#8316

On Wed, 08 Jul 2015 01:10:21 -0400, Alexei A. Frounze  
<alexfrunews@gmail.com> wrote:
> On Tuesday, July 7, 2015 at 2:40:05 AM UTC-7, Rod Pemberton wrote:
>> On Tue, 07 Jul 2015 04:44:33 -0400, Alexei A. Frounze
>> <...@gmail.com> wrote:

>> > I think you still don't realize the simple idea of a simple
>> > compiler as also evidenced by the earlier statement that the
>> > generation of jcc's is somehow wrong
>>
>> It is.
>>
>> > (and NASM being wrong as well,
>>
>> It is.
>
> AFAIK, you have provided nothing of substance to support the above
> claims, merely fears of the kind "oh, no, NASM's doing something
> behind my back, it can't be good, and Smaller C is supportive of
> that sin, run!".

The fact that I didn't want to get into a long discussion of these
issues seems to have provoked you.  I believe they're serious, but
why would I continue to spend time to discuss them with someone who
dismisses them as being trivial, as you just did? ...

I can say the almost the same thing about your blatant acceptance:

AFAIK, you have provided nothing of substance to support your claims,
only expressing absolute acceptance as "well, it looks like it works
to me, but I'm not about to check, and I trivialize serious details
without experience in them, and there couldn't have possibly been a
dozen reasons why a skilled C programmer and x86 assembly programmer
who has programmed for over 3 decades in over 16 languages would've
ever claimed such things since my experience doesn't indicate this!"

So, you prove it, dismissive bitch.  Prove that it makes no
difference.  IMO, I'm sitting well here by knowing of a few
situations with NASM where I know for a fact that it does.

>> > It's all by design, by a simple design.
>>
>> It's interesting that when I mention "simpler" designs and
>> method of implementations both here and elsewhere, e.g.,
>> comp.lang.asm.x86, comp.lang.misc, alt.lang.asm, etc that
>> everyone rejects my "simpler" design, which is provably so.
>
> I don't recall of a design of yours of a C compiler simpler
> and smaller than Smaller C and yet having all of its
> functionality and supporting at least the same architectures
> and platforms.

I didn't specifically mention a C compiler.  As you well know or
should, we don't just exclusively discuss C compilers here, but
mostly OS development.  And, I obviously indicated other
conversations elsewhere on other topics which didn't include you.

So, did you miss the point or just ignore it?  The point was why
shouldn't other people on Usenet criticize your designs, when
they criticize everyone's designs.  Makes sense, yes?  I.e., why
should I be the exception to the rule when it comes to you?  That
would seem to be arrogant.

> I doubt there is one. If there is, I'm all ears. If there isn't,
> the above talk about so-provable simpler designs is just an
> irrelevant (in the context of Smaller C) blabber.

For a small C compiler, I was working with SmallC.  I still might
again someday.  It only had a few areas that needed more development
for use as a bootstrap compiler.  Unfortunately, Steve, who helped
out a lot, chose a different path from the version I was working on.

For a full C compiler, I was using OpenWatcom and DJGPP (GCC).

> So, is there?

(FYI, I've answered this same question _at least_ twice previously
for you ...  How is your memory today?)

I have a number of C parsers of my own designs.  I haven't worked
on many of them in some years.  Most of my time was spent on my
OS project, not on compilers, parsers, and assemblers, which came
later.  I do have many other projects including a simpler language
and assembler which emits code, as well as other projects that do,
such a simple Forth to assembly.  So, most of my C parsers are
simple and not full compilers, although they could be, but as stated
I was using other completed C compilers for my needs.  One C parser
is rather complex.  It's a merger of code of mine from three or four
different projects.  It is capable of doing full C-to-C parsing
and C code transformations.  I.e., it's for reducing full C code
to simple C code that can be compiled by a bootstrap C compiler such
as SmallC, Bellard's TCC, or perhaps SmallerC.  Currently, it's
only set up with trivial stuff, but is not limited to them.  It
may still need some additional work to fully do so, but it's close
to being complete, if not.  If you had been reading my posts over
the years, even only while you were here, you'd probably remember
this.  Why?  Because, I've answered this numerous times for others
who've posted.

> Some of your suggested code improvements are impractical, because
> you either ignore the context or aren't sufficiently versed in it.

Apparently, you could say the same of James too, but not Ben.  So,
tell me, why did you chose to only mention that in regards to me? ...

AFAIR, the "context" you refer to was never stated here.  You've not
provided that info here, even with both James' and my questions about
SmallerC.  The info may be available to whomever looks at your source
code, but we're conversing directly with the original  *author*  of
said code, who appears to be totally ignorant of it when asked in
depth questions about it.  What gives?  We really shouldn't have to
go jumping through a bunch of time wasting hoops like trained sea
animals when you can answer directly.

> AFAIK, to date you still haven't used Smaller C beyond just one
> short stint

I did? ...  I don't recall that.  Maybe, I did.  I've looked at
numerous projects over the years, including many of your other projects.
I've provided links to them when you weren't here and recommended some
too.  I do recall offering to run the SmallerC code through other C
compilers for possible errors, but you never responded to that.  So,
I took it that that proffer offended you, i.e., ISTM you took it as
an insult that there could possibly be errors in your code ...
Currently, you seem to be taking the suggestion that anyone could
improve your code as an insult too, i.e., your recent comments to me.
Yet, you let Ben make additions and changes for things he wanted.
These even complicated your simpler SmallerC C compiler which is
something you've repeatedly insisted to me in this thread that you
simply aren't willing to do.  Contradiction?  Conundrum.

> and I'm certain you have spent even less time reading and
> understanding its code/design.

So?  This discussion was started by James on his issues, and shifted
to James having 8086 issues supposedly with SmallerC and NASM.  So,
tell me, just when did this thread become the "Alexei Frounze"
SmallerC show?  It seems you're attempting to usurp the thread.  This
appears to be an ego issue from my perspective.  Am I wrong?  It also
seems that you're always attempting to make demands of me and my time.

> Doesn't it feel good to be generous, Rod, when you give something
> to others?

I always give to others.  You don't, ever, it seems, AFAIR.

Did you forget I've been posting here for almost a decade and I have
excellent recall?  When subscribed here and posting, you only post
under a few circumstances:

1) you need someone's help  (which is rare...)
2) you're promoting your code, as you're doing with SmallerC now
3) you want to be argumentative or negative or hostile or an asshole

I've  *NEVER*  seen you help anyone else out with their code or projects
on a.o.d.  Where were you when I was doing E802h memory maps?  Where
were you when James was doing A20 and other other machine characteristics
tests?  Where were you when Ben was doing his OHCI, UHCI, EHCI, XHCI
tests and FYSOS OS tests?  You're always missing in action, MIA, when
it comes to helping out others here.  Why would you expect others to
help you out?  When did you earn any goodwill?  Those are all recent
examples, i.e., within the past few years.  Where where you when Steve
was working on SmallC, DrAcOnUx was working on Linux 0.01 remake, when
Paul Edwards was working on his PDOS and PDPCLIB, Brendan Trotter on
BCOS, Kristof Benes on Cribix, Peter Cheung on POS, Paul Hulme on Thix
OS, Marvin Lee with his personal OS, BGB/cr88192 on his personal OS,
or even Mike Gonta with aeBIOS, etc.

You.  MIA.  Always.

(Ben is frequently MIA too.  He says he's busy.)

> Well, sorry, impractical suggestions are of little value
> to the recipients.

Sociopath?  Why would you assume that the information was  *exclusively*
intended for you?  Perhaps, it wasn't even intended for you at all.  I.e.,
it might be useful to James or others here, or even someone in the future.
There are many lurkers who don't post or can't post to Usenet.  I search
old Usenet posts all the time for useful info, especially in regards
to my Forth interpreter in C project.

>> So, why should you be any different? ...  ;-)
>
> You mean, why shouldn't I reject your simpler designs just as well?
> Or you mean, why shouldn't I be another Rod?

Was that an attempt at sarcasm or humor?

No, I mean what's wrong with your ego that you can't accept input
 from others without harsh judgement of them?  You ask for others to
use your projects, but when they make comments about them, or make
general discussion related to them, you explode emotionally and
attack them ...  AFAIR, the only person over the past decade you
haven't done that to at some point in time was recently with Ben.

> I have to remind you yet again that special casing is useful
> but complicates and inflates code, which is something I prefer
> to avoid in Smaller C.

You initially indicated your intent to help James.  Have you rescinded
that intent?  That is what this conversation has all been about despite
your attempts to change focus to SmallerC.  You can start a new thread
on SmallerC, as you have in the past, if you wish to discuss SmallerC.
E.g., post some code, ask questions.  That would be easier than either
James or I asking you questions to obtain the "context" and you turning
around and stating we don't know the "context".  Provide it.


Rod Pemberton

-- 
Tolerance and socialism attracts intolerance and terrorism.  See:
France, United Kingdom, Germany, Denmark, Belgium, Netherlands, ...
UK: Strong encryption, non-issue. GR: Eurozone currency, priority.

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

#8318

On Wednesday, July 8, 2015 at 12:52:36 AM UTC-7, Rod Pemberton wrote:
> On Wed, 08 Jul 2015 01:10:21 -0400, Alexei A. Frounze  
> <...@gmail.com> wrote:
> > On Tuesday, July 7, 2015 at 2:40:05 AM UTC-7, Rod Pemberton wrote:
> >> On Tue, 07 Jul 2015 04:44:33 -0400, Alexei A. Frounze
> >> <...@gmail.com> wrote:
> 
> >> > I think you still don't realize the simple idea of a simple
> >> > compiler as also evidenced by the earlier statement that the
> >> > generation of jcc's is somehow wrong
> >>
> >> It is.
> >>
> >> > (and NASM being wrong as well,
> >>
> >> It is.
> >
> > AFAIK, you have provided nothing of substance to support the above
> > claims, merely fears of the kind "oh, no, NASM's doing something
> > behind my back, it can't be good, and Smaller C is supportive of
> > that sin, run!".
> 
> The fact that I didn't want to get into a long discussion of these
> issues seems to have provoked you. 

Provoked me how or to do what?

> I believe they're serious, but
> why would I continue to spend time to discuss them with someone who
> dismisses them as being trivial, as you just did? ...

You didn't show where I was wrong with that dismissal of things as
trivial. I, OTOH, told you that I had in fact successfully coded up
a boot sector with NASM (the code is online), which you'd claimed
was no longer suitable for the task. I did enumerate most(?) of the
rare and non-trivial things you do in assembly (e.g. self-mod code,
code=data and such), where you must be very careful w.r.t. encoding,
but which aren't typical things to do. What examples/situations did
you provide to counter or complement my view of the matter?

> I can say the almost the same thing about your blatant acceptance:
> 
> AFAIK, you have provided nothing of substance to support your claims,
> only expressing absolute acceptance as "well, it looks like it works
> to me, 

"it" being what?

> but I'm not about to check, and I trivialize serious details
> without experience in them,

What serious details? Did you provide an example of such serious
details? Do they exist? Can we be shown them so we can possibly
assess their seriousness?

> and there couldn't have possibly been a
> dozen reasons why a skilled C programmer and x86 assembly programmer
> who has programmed for over 3 decades in over 16 languages would've
> ever claimed such things since my experience doesn't indicate this!"

I couldn't say all of that, unless, perhaps, I analyzed all your posts
(provided they were truthful about these professional details) or
cared enough to memorize everything read or keep tabs on everyone or
hired some kind of private detective to find out about the 3 decades
and the 16+ languages that you mention. You don't seem to be on the
major social networks and, while I don't say you don't exist or the
above is untrue, other than USENET I have no other information
traceable to you to corroborate any of that. I can't say all of that.
You say that. But it doesn't really matter. I'm not here to enter a
contest of who's older (and, perhaps, has to be believed and respected
just because of their age and vice versa), who's been in the industry
for longer or who has programmed in more/most languages and so on.
All of this info is not necessarily indicative or consequential, at
least not at the level of detail provided. I don't remember ever
seeing any of your code other than the relatively small snippets here
and there to form an opinion of you being a decent or even great
programmer. If you happen to have some open source projects on a
homepage or on github and such, I'll gladly see their code. So
far my opinion of you as a programmer is mixed at best. On one
hand you seem to have amassed some good knowledge about specific
things (or the notes that you mention and the helpful links that
you provide) and you seem to show unprecedented deep/detailed
treatment of certain things, but on the other hand from our
discussions about C in this group I get that you aren't a good/
skilled C programmer. Maybe, you were in pre-K&R 2nd.ed./pre-
ANSI C days, but I can't see it now. My experience doesn't
indicate it, sorry. So, again, even if I wanted to take into
account your vast C knowledge and skill, I couldn't possibly do it.
But then again, in the discussion of NASM's treatment of branches
and Smaller C's generation of branches that are then fed into NASM
that isn't very important. This branch issue is not an issue for
the pair of Smaller C and NASM. It may be more of an issue in other
cases. I think those are rare and require special explicit treatment.
If I missed something that isn't rare or very special, but is very
important in how branches are generated and handled, please do provide
the relevant examples. And I then will either agree with you or not. :)

> So, you prove it,

Like I said, please provide further examples (in addition to mine) to
substantiate your view and to possibly augment mine if mine is wrong.
Why do you write so much text, pepper it with expletive(s), get
personal and yet provide no examples in it to prove or support
your view of which you are very certain?

> dismissive bitch. 

I'm not a female and I'm not anyone's bitch.
Provide the examples. And I'll either further dismiss them or not.

> Prove that it makes no
> difference.  IMO, I'm sitting well here by knowing of a few
> situations with NASM where I know for a fact that it does.

I may admit being wrong, but you need to provide the examples/
situations, which shouldn't be a problem for you to do, right?

> >> > It's all by design, by a simple design.
> >>
> >> It's interesting that when I mention "simpler" designs and
> >> method of implementations both here and elsewhere, e.g.,
> >> comp.lang.asm.x86, comp.lang.misc, alt.lang.asm, etc that
> >> everyone rejects my "simpler" design, which is provably so.
> >
> > I don't recall of a design of yours of a C compiler simpler
> > and smaller than Smaller C and yet having all of its
> > functionality and supporting at least the same architectures
> > and platforms.
> 
> I didn't specifically mention a C compiler.  As you well know or
> should, we don't just exclusively discuss C compilers here, but
> mostly OS development.  And, I obviously indicated other
> conversations elsewhere on other topics which didn't include you.

But did we not put in focus Smaller C and NASM in this thread over
the 8086 support? Once we did, we did.

> So, did you miss the point or just ignore it?  The point was why
> shouldn't other people on Usenet criticize your designs, when
> they criticize everyone's designs.  Makes sense, yes? 

That's alright. And disagreeing is OK. So, I disagree with some
of your points and statements.

> I.e., why
> should I be the exception to the rule when it comes to you?  That
> would seem to be arrogant.

No, why? Criticize away. I reserve the right to disagree.

> > I doubt there is one. If there is, I'm all ears. If there isn't,
> > the above talk about so-provable simpler designs is just an
> > irrelevant (in the context of Smaller C) blabber.
> 
> For a small C compiler, I was working with SmallC.  I still might
> again someday.  It only had a few areas that needed more development
> for use as a bootstrap compiler.  Unfortunately, Steve, who helped
> out a lot, chose a different path from the version I was working on.
> 
> For a full C compiler, I was using OpenWatcom and DJGPP (GCC).

OK.

> > So, is there?
> 
> (FYI, I've answered this same question _at least_ twice previously
> for you ...  How is your memory today?)
> 
> I have a number of C parsers of my own designs.  I haven't worked
> on many of them in some years.  Most of my time was spent on my
> OS project, not on compilers, parsers, and assemblers, which came
> later.  I do have many other projects including a simpler language
> and assembler which emits code, as well as other projects that do,
> such a simple Forth to assembly.  So, most of my C parsers are
> simple and not full compilers, although they could be, but as stated
> I was using other completed C compilers for my needs.  One C parser
> is rather complex.  It's a merger of code of mine from three or four
> different projects.  It is capable of doing full C-to-C parsing
> and C code transformations.  I.e., it's for reducing full C code
> to simple C code that can be compiled by a bootstrap C compiler such
> as SmallC, Bellard's TCC, or perhaps SmallerC.  Currently, it's
> only set up with trivial stuff, but is not limited to them.  It
> may still need some additional work to fully do so, but it's close
> to being complete, if not.  If you had been reading my posts over
> the years, even only while you were here, you'd probably remember
> this.  Why?  Because, I've answered this numerous times for others
> who've posted.

Yes, I've heard from you about your OS and compiler/language
projects. I'm vague on the latter because it wasn't a typical thing
to discuss in this group and because I myself turned to compilers
only recently.

> > Some of your suggested code improvements are impractical, because
> > you either ignore the context or aren't sufficiently versed in it.
> 
> Apparently, you could say the same of James too, but not Ben.  So,
> tell me, why did you chose to only mention that in regards to me? ...

Sorry, if I made you feel exceptional in this regard. But maybe you
are somehow special.

> AFAIR, the "context" you refer to was never stated here. 

You have read the Smaller C documentation (wiki), even suggested to
include it in the .ZIP file that github lets you download, which
was something surprising to me because I had not uploaded any .ZIP
files there. The documentation states that Smaller C is a simple
and small compiler, it states that it currently supports the 80386
and higher (not lower). The same document lists the various
limitations and implementation details. I have also expressed
several times (at least to Ben, and in this very group) my
reluctance to add a feature or change something in a particular
way on the grounds of that making the compiler:
- larger
- more complex (the x86 code generator/backend being the worst,
also mentioned not once or twice)
- no longer self-compilable
Is that not Smaller C context? Or did you want all of it collected,
condensed and presented in a single post? If you did, I'm sorry, I
didn't see the need to.

> You've not
> provided that info here, even with both James' and my questions about
> SmallerC. 

I lost you here, what questions?

> The info may be available to whomever looks at your source
> code, but we're conversing directly with the original  *author*  of
> said code, who appears to be totally ignorant of it when asked in
> depth questions about it.  What gives? 

I really lost you here. What are you talking about? Me being ignorant
of my own code? Did you really just say that? How so? What in-depth
questions? Are you still talking about Smaller C and me?

> We really shouldn't have to
> go jumping through a bunch of time wasting hoops like trained sea
> animals when you can answer directly.

I don't know what you're talking about.

[But I do remember asking you several times about your treatment of
the switch statement in C and you never replied to that. You only
replied to my hypotheses as to why you hadn't replied. It's been
several months since the last poke on the switch statement subject.
That was about answering directly and wasting time.]

So, what the heck are you talking about?

> > AFAIK, to date you still haven't used Smaller C beyond just one
> > short stint
> 
> I did? ...  I don't recall that.  Maybe, I did. 

You compiled it with Open Watcom (1.3 or 1.6, AFAIR), as you said
yourself. Per your own words it appeared that OW miscompiled it in
the expressions like a << b << c, where it made unsound optimizations
by changing such expressions to a << (b + c) and therefore invoking
UB with a bogus (truncated) shift count. I'm sure you with your
excellent recall, as you boast below, can find these posts in the
group.

> I've looked at
> numerous projects over the years, including many of your other projects.
> I've provided links to them when you weren't here and recommended some
> too.  I do recall offering to run the SmallerC code through other C
> compilers for possible errors, but you never responded to that. 

Perhaps, you did offer that. If I failed to respond to that, I can tell
you of the results of compiling smlrc.c with different compilers:
- Turbo C++ 1.01: OK
- gcc (DJGPP, MinGW, plain gcc on Linux, cross compiler for MIPS): OK
- Open Watcom C/C++: OK in version 1.9, problems reported by yourself
with 1.3 or 1.6, I have filed a bunch of nasty bugs against OW because
OW is in fact broken
- Visual C++ Studio: supposedly OK (per Ben, who uses it to compile
Smaller C)
I have no bugs on github related to Smaller C being miscompiled or
working incorrectly in weird ways that are compiler-specific.

> So,
> I took it that that proffer offended you, i.e., ISTM you took it as
> an insult that there could possibly be errors in your code ...

There could be, but not in the one or two places where you said
(e.g. in expressions like a << b << c). And I know of at least one
that does exist (but you need to run out of disk space to experience
it). If I ever did say the code was 100% error free in its entirety
with zero chance of bugs, I was clearly wrong. But I doubt I could
say that. I most likely said there wasn't a bug where you thought
there was or that it was unlikely for there to be a bug (let alone
many bugs), but not impossible. Anyhow, there was no offense w.r.t.
trying compiling Smaller C with different compilers. There's
nothing new to me here. I do have experience writing portable code.

> Currently, you seem to be taking the suggestion that anyone could
> improve your code as an insult too,

No, you seem to be the only person here being concerned about
insults and yet becoming personal in not-so-very-good ways 
(I'm again referring to your custom of referring to people's mental
state; btw, I've run this with another person, who speaks English
better than myself who has a better understanding of the culture
and the spectrum of polite and impolite things and she agreed
that referring to one's mental state (and we aren't talking the
happy states, there would be no issue with that!) is quite bad)
and as of lately you seem to be the only person directly insulting
others with words like bitch. Did you not just call me bitch, Rod?
Did I imagine it in a dream?

No. I'm "taking the suggestion that anyone could improve [Smaller C]
code" with ease, while still keeping things simple and small, more
of a fantasy than reality. You can suggest all you want, but you yourself
will unlikely do it (and if I don't do it and nobody else does it,
you won't get it and your suggestion will remain nice and generous,
but unfulfilled and nothing more).
It's not impossible to make changes and improvements, I do them
and I applaud Ben for his heroic efforts and for the results. However,
apart from mostly trivial stuff, of the several efforts that I'm aware of
to port Smaller C to another architecture (and even to an architecture
astonishingly similar to MIPS, for which there already is a rather clean
code generator/backend), none has succeeded so far. In one case (TR3200),
seeing that things aren't quite working out (the Smaller C project
was forked and changed and then subsequently deleted), I wrote a new
code generator to help the guy(s) out because for me it was just
a day of work and I did have that day (Jan 1st was a day off) and I
felt like doing it.

> i.e., your recent comments to me.
> Yet, you let Ben make additions and changes for things he wanted.

The project is open source, licensed under a 2-clause BSD license,
and you and everyone is free to get a copy and modify it and possibly
contribute some of the changes back to the original project (I don't
and won't take everything, only what I find reasonable in my view).
You can do anything you want with it. You can even print it out and
burn it if you like (or rather dislike). What issue do you find with
that? Not enough freedom?

Ben has shown to me some of his changes (in this group), but I didn't
like what they did or how they did it. So, I didn't take them. If I
needed the same functionality, I implemented it myself in a more
appropriate for the project way and let Ben know (e.g. his
implementation of for(declaration;;) had a bug and there was
something else with structs, which at the time weren't supported AFAIR).
Ben is free to develop and maintain his variant of Smaller C for his
purposes. And so are you and James and whoever else might want to.
There's the license and my right not to take your contributions into
the main project. Those are the only restrictions. And I will not
mourn the good name of the project if you destroy it by doing something
horrible in or with your version of it. :)

> These even complicated your simpler SmallerC C compiler which is
> something you've repeatedly insisted to me in this thread that you
> simply aren't willing to do.  Contradiction?  Conundrum.

Nope. You're right, I'm unwilling to touch certain bad parts at the
moment (due to other priorities and lack of a large span of free time).
And I don't expect you'd do it for me. Or am I wrong and you're willing
to contribute beyond suggestions? With actual code? If you would,
I'd help out with explaining stuff and reviewing (and to some extent
testing) your changes. Again, I don't guarantee I will accept all
changes or in their original form, but we could try. What do you say?

> > and I'm certain you have spent even less time reading and
> > understanding its code/design.
> 
> So?  This discussion was started by James on his issues, and shifted
> to James having 8086 issues supposedly with SmallerC and NASM.  So,
> tell me, just when did this thread become the "Alexei Frounze"
> SmallerC show?

When you made that decision?

> It seems you're attempting to usurp the thread. 

I don't deprive you of its posts in any way. You have your copy of them.
Just like you can have a copy of Smaller C any day.

> This
> appears to be an ego issue from my perspective.  Am I wrong? 

No comment.

> It also
> seems that you're always attempting to make demands of me and my time.

Ditto. :)

> > Doesn't it feel good to be generous, Rod, when you give something
> > to others?
> 
> I always give to others. 

Always? Can't be proven.

> You don't, ever, it seems, AFAIR.

Never? Can't be proven either. Or it only seems because you're not
looking or you are looking but not seeing?

> Did you forget I've been posting here for almost a decade and I have
> excellent recall? 

I think you have a regular recall and some reasonable bookkeeping.

> When subscribed here and posting, you only post
> under a few circumstances:
> 
> 1) you need someone's help  (which is rare...)

Right, as of lately.

> 2) you're promoting your code, as you're doing with SmallerC now

Right, as of lately.

> 3) you want to be argumentative or negative or hostile or an asshole

Argumentative, negative, hostile and asshole not more than yourself.

> I've  *NEVER*  seen you help anyone else out with their code or projects
> on a.o.d. 

Well, if you've been posting here for a decade and have never seen it
during all this time, something must be wrong with your seeing or recall.

> Where were you when I was doing E802h memory maps? 

Did I promise to help there or was I somehow obligated to? Was it
something so horribly obscure and complex, where another person's
input would've made much difference or were I the only person
to be able to provide some help/answers? You did just fine, IMO.

> Where
> were you when James was doing A20 and other other machine characteristics
> tests? 

Ditto.

> Where were you when Ben was doing his OHCI, UHCI, EHCI, XHCI
> tests and FYSOS OS tests? 

Not my area of expertise and I don't have much to test this stuff
on.

> You're always missing in action, MIA, when
> it comes to helping out others here.  Why would you expect others to
> help you out?  When did you earn any goodwill?  Those are all recent
> examples, i.e., within the past few years.  Where where you when Steve
> was working on SmallC, DrAcOnUx was working on Linux 0.01 remake, when
> Paul Edwards was working on his PDOS and PDPCLIB, Brendan Trotter on
> BCOS, Kristof Benes on Cribix, Peter Cheung on POS, Paul Hulme on Thix
> OS, Marvin Lee with his personal OS, BGB/cr88192 on his personal OS,
> or even Mike Gonta with aeBIOS, etc.
> 
> You.  MIA.  Always.

Always? Really? Look up earlier posts, maybe in the more active days
of a.o.d and c.l.a.x86, between like 1998 and 2005. Look up at least
those posts, where I gave hints or pointed at bugs in protected mode
code. Was that always MIA or was that not? Please also make sure to
look in those other groups, where I posted. Btw, I have made some 350+
posts on http://forum.osdev.org/ in the past year or so.
Have you forgotten about the book translation, in which I participated
recently pro bono for like 5 months all weekends? You can download it
and you can find my name in it. Please don't say it doesn't count
because it's in Russian, which you don't understand, or because it
isn't about OS-dev. How about the RetroBSD project, which is kinda
about OS-dev? I didn't contribute just Smaller C to it. I filed
bugs, helped troubleshooting and fixing some of non-Smaller C issues,
contributed sample code. Did I not contribute over 1K answers to
http://stackoverflow.com/ from 2011 to 2013 on subjects of C, assembly,
kernel and other low-level stuff?

So, you have an issue with me just because I rarely post here,
in an almost dead USENET group? And that is enough for you to say
"I always give to others. ... You don't, ever, it seems, AFAIR."?
What world do you live in, Rod? Should I follow suit and similarly
inquire about your mental state for finding the reasons for such
broad and bold statements of yours?

> (Ben is frequently MIA too.  He says he's busy.)

Ben has family, work and personal interests. As pretty much everyone.
Such is life. If you are somehow overloaded with the activity on
a.o.d and can't manage it all by yourself, guess what, you're not
required to help everyone with everything everywhere and you may do
less of helping, even none of it. I chose where I help and how.
And so can you.

> > Well, sorry, impractical suggestions are of little value
> > to the recipients.
> 
> Sociopath?  Why would you assume that the information was  *exclusively*
> intended for you? 

When you say something's wrong in Smaller C, of which I'm the author,
and I'm in the thread, it's not exclusive, but it includes me and I
may voice my opinion and disagreement.

> Perhaps, it wasn't even intended for you at all.  I.e.,
> it might be useful to James or others here, or even someone in the future.
> There are many lurkers who don't post or can't post to Usenet.  I search
> old Usenet posts all the time for useful info, especially in regards
> to my Forth interpreter in C project.
> 
> >> So, why should you be any different? ...  ;-)
> >
> > You mean, why shouldn't I reject your simpler designs just as well?
> > Or you mean, why shouldn't I be another Rod?
> 
> Was that an attempt at sarcasm or humor?

I didn't get the question. The syntax and grammar parsed OK, but
the meaning escaped. So, I tried to clarify it with two possible
meanings I could quickly come up with based on the preceding text.

> No, I mean what's wrong with your ego that you can't accept input
>  from others without harsh judgement of them? 

I can. I accept your references to my mental states, sociopaths,
bitches and other things and am still talking to you nonetheless.
I could just stop talking to you after all this linguistic abuse,
as people often do, but I think we may still hold meaningful
conversations from time to time, with criticism and everything.
But I'd really prefer that you stop referring to people's mental
states and call them bitches and assholes and whatever else you
have in the reserves. You outnumber me in the use of such direct
and almost direct insults and I could likewise wonder as to what's
wrong with you if that's what you have to resort to when talking
to me. You asked above why I was singling you out. Maybe because
you are singling me out? I don't know what you think, but I'm
not your bitch.

> You ask for others to
> use your projects, but when they make comments about them, or make
> general discussion related to them, you explode emotionally and
> attack them ... 

It looks like it's you who's exploding emotionally. I'm doing fine,
thank you.

> AFAIR, the only person over the past decade you
> haven't done that to at some point in time was recently with Ben.

The grammar didn't parse here. Past decade or recently? Or are the
two the same thing?

> > I have to remind you yet again that special casing is useful
> > but complicates and inflates code, which is something I prefer
> > to avoid in Smaller C.
> 
> You initially indicated your intent to help James.  Have you rescinded
> that intent? 

I did communicate my unwillingness to code up and include support for
anything below the 80386 and my surprise as to why anyone would need the
8086 these days (AFAIR, intel isn't hasn't manufactured one since 2007,
which is probably a good indicator for the end of the 8086 days) and
at the same time I did indicate my willingness to help if he starts
coding it himself and needs some help. I think that's accurate. You
can check with your records, you have the posts.

> That is what this conversation has all been about despite
> your attempts to change focus to SmallerC.  You can start a new thread
> on SmallerC, as you have in the past, if you wish to discuss SmallerC.
> E.g., post some code, ask questions.  That would be easier than either
> James or I asking you questions to obtain the "context" and you turning
> around and stating we don't know the "context".  Provide it.

We were doing just fine. I expressed my opinion that DOS .EXEs and
ELFs are sufficient and that my compiler generates both and thus
can be used for 16-bit real mode code and 32-bit protected mode code.
James said he wanted 8086 code and that Smaller C didn't generate it.
Then we started discussing what was non-8086 in Smaller C's output
and there were some suggestions as to how to turn that into 8086
instructions. So far so good. Nobody objected Smaller C in the least.
Then you include "6) NASM auto-generated long branches" with
subbullets, where you were suggesting that something was needed
to be done either in Smaller C or in NASM or in both. I disagreed
with your view of the matter. You disagreed with mine. We then
discovered that the recent versions of NASM do what Smaller C needs
from NASM w.r.t. long branches even when the CPU 8086 directive is
used (you get desired 8086 code). You kept insisting that Smaller C
and NASM were wrong and that NASM is no longer kosher and suitable
for boot loaders (somehow suitable for mine) and so on and that you
wanted to blame H.P.A. for it (just note who here introduces
negativity and blame) and several posts later here we are and
suddenly it's me who attempted (multiple times per your words) to
change the focus to Smaller C (nobody noticed until now that it
was there almost from the beginning?) and so on.

Alex

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

#8322

"Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message 
news:op.x1f2t8iayfako5@localhost...
> On Wed, 08 Jul 2015 01:10:21 -0400, Alexei A. Frounze 
> <alexfrunews@gmail.com> wrote:

...

> The fact that I didn't want to get into a long discussion of these
> issues seems to have provoked you.

ISTM from what Alexei wrote that he wasn't especially provoked.

...

>> Some of your suggested code improvements are impractical, because
>> you either ignore the context or aren't sufficiently versed in it.
>
> Apparently, you could say the same of James too, but not Ben.  So,
> tell me, why did you chose to only mention that in regards to me? ...

They are out to get you.

  http://www.onelook.com/?w=paranoia&ls=a

;-)

...

>> and I'm certain you have spent even less time reading and
>> understanding its code/design.
>
> So?  This discussion was started by James on his issues, and shifted
> to James having 8086 issues supposedly with SmallerC and NASM.  So,
> tell me, just when did this thread become the "Alexei Frounze"
> SmallerC show?  It seems you're attempting to usurp the thread.

IMO this thread has not been usurped at all. It is just normal thread 
drift.

I think you read this one wrong, Rod. Chill, Man!

James

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

#8342

On Wednesday, July 8, 2015 at 2:52:36 AM UTC-5, Rod Pemberton wrote:
> On Wed, 08 Jul 2015 01:10:21 -0400, Alexei A. Frounze  
> <alexfrunews@gmail.com> wrote:
> > On Tuesday, July 7, 2015 at 2:40:05 AM UTC-7, Rod Pemberton wrote:
> >> On Tue, 07 Jul 2015 04:44:33 -0400, Alexei A. Frounze
> >> <...@gmail.com> wrote:
> 

[Rod]

> For a small C compiler, I was working with SmallC.  I still might
> again someday.  It only had a few areas that needed more development
> for use as a bootstrap compiler.

Just to say, to me, a bootstrap compiler is a self-compiling compiler that can
be bootstrapped to a new OS architecture with a minimum of fuss.  The 'minimum
of fuss' means a hand full of IO interface functions written in in-line
assembler.  The usual strategy has the compiler emitting assembler syntax for a
presumed available assembler program on the target OS.

SmallC fits that, but for a subset of K&R C.  The 'subset' really means that it
is its own language, in the comp.sci sense.  It can't handle 'struct', so it is
more correct to call it something like 'C subscript 0', or something, so as not
to confuse its capabilities with a full K&R C compiler.  I have seen versions
for the Z80 which have advanced smallc from C_sub_0 to nearly C_sub_K&R, which represent perhaps dozens of sub languages in-between to get there.  It is an
art to do a small modification to a compiler to implement a new parsing
capability to cover more of the full language syntax.  This can only be done in
steps so the existing compiler can handle it, and yet produce a new superset
compiler.  It ends up that C0 can build C1, C1 can build C2, but C0 cannot
parse C2.

>  Unfortunately, Steve, who helped
> out a lot, chose a different path from the version I was working on.
>

I know you were working on parsing 'void'.
Perhaps you could explain "chose a different path", and "unfortunately".

From my standpoint, I was running out of room in 64k, and implemented
'segmentation' regarding putting code in .code and data in .data and IIRC,
stack in .stack.  Perhaps that is the 'different path' you mean?

Anyway, messing with small c was enjoyable and informative, but time constraints
are constraining.

And Alex has leapfrogged to a modern C with SmallerC.

I think I proffered that idea (start from scratch) to you at some point as an
'end around' moving small c (K&Rish) to an ANSI version.  Maybe your
recollection is different.

Steve

 
> For a full C compiler, I was using OpenWatcom and DJGPP (GCC).
> 
> > So, is there?
> 
> (FYI, I've answered this same question _at least_ twice previously
> for you ...  How is your memory today?)
> 
> I have a number of C parsers of my own designs.  I haven't worked
> on many of them in some years.  Most of my time was spent on my
> OS project, not on compilers, parsers, and assemblers, which came
> later.  I do have many other projects including a simpler language
> and assembler which emits code, as well as other projects that do,
> such a simple Forth to assembly.  So, most of my C parsers are
> simple and not full compilers, although they could be, but as stated
> I was using other completed C compilers for my needs.  One C parser
> is rather complex.  It's a merger of code of mine from three or four
> different projects.  It is capable of doing full C-to-C parsing
> and C code transformations.  I.e., it's for reducing full C code
> to simple C code that can be compiled by a bootstrap C compiler such
> as SmallC, Bellard's TCC, or perhaps SmallerC.  Currently, it's
> only set up with trivial stuff, but is not limited to them.  It
> may still need some additional work to fully do so, but it's close
> to being complete, if not.  If you had been reading my posts over
> the years, even only while you were here, you'd probably remember
> this.  Why?  Because, I've answered this numerous times for others
> who've posted.
> 
> > Some of your suggested code improvements are impractical, because
> > you either ignore the context or aren't sufficiently versed in it.
> 
> Apparently, you could say the same of James too, but not Ben.  So,
> tell me, why did you chose to only mention that in regards to me? ...
> 
> AFAIR, the "context" you refer to was never stated here.  You've not
> provided that info here, even with both James' and my questions about
> SmallerC.  The info may be available to whomever looks at your source
> code, but we're conversing directly with the original  *author*  of
> said code, who appears to be totally ignorant of it when asked in
> depth questions about it.  What gives?  We really shouldn't have to
> go jumping through a bunch of time wasting hoops like trained sea
> animals when you can answer directly.
> 
> > AFAIK, to date you still haven't used Smaller C beyond just one
> > short stint
> 
> I did? ...  I don't recall that.  Maybe, I did.  I've looked at
> numerous projects over the years, including many of your other projects.
> I've provided links to them when you weren't here and recommended some
> too.  I do recall offering to run the SmallerC code through other C
> compilers for possible errors, but you never responded to that.  So,
> I took it that that proffer offended you, i.e., ISTM you took it as
> an insult that there could possibly be errors in your code ...
> Currently, you seem to be taking the suggestion that anyone could
> improve your code as an insult too, i.e., your recent comments to me.
> Yet, you let Ben make additions and changes for things he wanted.
> These even complicated your simpler SmallerC C compiler which is
> something you've repeatedly insisted to me in this thread that you
> simply aren't willing to do.  Contradiction?  Conundrum.
> 
> > and I'm certain you have spent even less time reading and
> > understanding its code/design.
> 
> So?  This discussion was started by James on his issues, and shifted
> to James having 8086 issues supposedly with SmallerC and NASM.  So,
> tell me, just when did this thread become the "Alexei Frounze"
> SmallerC show?  It seems you're attempting to usurp the thread.  This
> appears to be an ego issue from my perspective.  Am I wrong?  It also
> seems that you're always attempting to make demands of me and my time.
> 
> > Doesn't it feel good to be generous, Rod, when you give something
> > to others?
> 
> I always give to others.  You don't, ever, it seems, AFAIR.
> 
> Did you forget I've been posting here for almost a decade and I have
> excellent recall?  When subscribed here and posting, you only post
> under a few circumstances:
> 
> 1) you need someone's help  (which is rare...)
> 2) you're promoting your code, as you're doing with SmallerC now
> 3) you want to be argumentative or negative or hostile or an asshole
> 
> I've  *NEVER*  seen you help anyone else out with their code or projects
> on a.o.d.  Where were you when I was doing E802h memory maps?  Where
> were you when James was doing A20 and other other machine characteristics
> tests?  Where were you when Ben was doing his OHCI, UHCI, EHCI, XHCI
> tests and FYSOS OS tests?  You're always missing in action, MIA, when
> it comes to helping out others here.  Why would you expect others to
> help you out?  When did you earn any goodwill?  Those are all recent
> examples, i.e., within the past few years.  Where where you when Steve
> was working on SmallC, DrAcOnUx was working on Linux 0.01 remake, when
> Paul Edwards was working on his PDOS and PDPCLIB, Brendan Trotter on
> BCOS, Kristof Benes on Cribix, Peter Cheung on POS, Paul Hulme on Thix
> OS, Marvin Lee with his personal OS, BGB/cr88192 on his personal OS,
> or even Mike Gonta with aeBIOS, etc.
> 
> You.  MIA.  Always.
> 
> (Ben is frequently MIA too.  He says he's busy.)
> 
> > Well, sorry, impractical suggestions are of little value
> > to the recipients.
> 
> Sociopath?  Why would you assume that the information was  *exclusively*
> intended for you?  Perhaps, it wasn't even intended for you at all.  I.e.,
> it might be useful to James or others here, or even someone in the future.
> There are many lurkers who don't post or can't post to Usenet.  I search
> old Usenet posts all the time for useful info, especially in regards
> to my Forth interpreter in C project.
> 
> >> So, why should you be any different? ...  ;-)
> >
> > You mean, why shouldn't I reject your simpler designs just as well?
> > Or you mean, why shouldn't I be another Rod?
> 
> Was that an attempt at sarcasm or humor?
> 
> No, I mean what's wrong with your ego that you can't accept input
>  from others without harsh judgement of them?  You ask for others to
> use your projects, but when they make comments about them, or make
> general discussion related to them, you explode emotionally and
> attack them ...  AFAIR, the only person over the past decade you
> haven't done that to at some point in time was recently with Ben.
> 
> > I have to remind you yet again that special casing is useful
> > but complicates and inflates code, which is something I prefer
> > to avoid in Smaller C.
> 
> You initially indicated your intent to help James.  Have you rescinded
> that intent?  That is what this conversation has all been about despite
> your attempts to change focus to SmallerC.  You can start a new thread
> on SmallerC, as you have in the past, if you wish to discuss SmallerC.
> E.g., post some code, ask questions.  That would be easier than either
> James or I asking you questions to obtain the "context" and you turning
> around and stating we don't know the "context".  Provide it.
> 
> 
> Rod Pemberton
> 
> -- 
> Tolerance and socialism attracts intolerance and terrorism.  See:
> France, United Kingdom, Germany, Denmark, Belgium, Netherlands, ...
> UK: Strong encryption, non-issue. GR: Eurozone currency, priority.

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

#8351

On Sat, 11 Jul 2015 12:57:42 -0400, s_dubrovich@yahoo.com  
<s_dubrovich@yahoo.com> wrote:

> On Wednesday, July 8, 2015 at 2:52:36 AM UTC-5, Rod Pemberton wrote:
>> On Wed, 08 Jul 2015 01:10:21 -0400, Alexei A. Frounze
>> <alexfrunews@gmail.com> wrote:
>> > On Tuesday, July 7, 2015 at 2:40:05 AM UTC-7, Rod Pemberton wrote:
>> >> On Tue, 07 Jul 2015 04:44:33 -0400, Alexei A. Frounze
>> >> <...@gmail.com> wrote:

>> For a small C compiler, I was working with SmallC.  I still might
>> again someday.  It only had a few areas that needed more development
>> for use as a bootstrap compiler.
>
> Just to say, to me, a bootstrap compiler is a self-compiling compiler
> that can be bootstrapped to a new OS architecture with a minimum of
> fuss.  The 'minimum of fuss' means a hand full of IO interface functions
> written in in-line assembler.  The usual strategy has the compiler
> emitting assembler syntax for a presumed available assembler program
> on the target OS.
>
> SmallC fits that, but for a subset of K&R C.  The 'subset' really means
> that it is its own language,

It's still C.

Today, I only code in a subset of C, and that subset keeps getting smaller.
Does that make my C code not C code anymore? ...

> in the comp.sci sense.

Huh?

> It can't handle 'struct', so it is more correct to call it something
> like 'C subscript 0', or something,

Yes, that's one serious deficiency, although it doesn't make SmallC  
unuseable.

> so as not to confuse its capabilities with a full K&R C compiler.  I have
> seen versions for the Z80 which have advanced smallc from C_sub_0 to  
> nearly
> C_sub_K&R, which represent perhaps dozens of sub languages in-between to
> get there.

Ok.

> It is an art to do a small modification to a compiler to implement a new
> parsing capability to cover more of the full language syntax.  This can
> only be done in steps so the existing compiler can handle it, and yet
> produce a new superset compiler.  It ends up that C0 can build C1, C1 can
> build C2, but C0 cannot parse C2.

...

>>  Unfortunately, Steve, who helped
>> out a lot, chose a different path from the version I was working on.
>>
>
> I know you were working on parsing 'void'.
> Perhaps you could explain "chose a different path", and "unfortunately".

"chose a different path"

At some point, you decided to rewrite the compiler your own way.  I was
using SmallC source from a number of existing SmallC variants.  So, you
changes and direction won't work with the older/original code.  E.g., one
SmallC variant has structs, but that author also made other modifications
that weren't compatible with the earlier source.  The changes for struct
couldn't just be added to the earlier code.

"unfortunately"

The CP/M stdio library of yours allowed me to compile and work on it.
(IIRC, the NASM source helped to get it there too.)  Later on you
developed a DOS I/O routines which worked with your code, but not with
the earliest SmallC you started with, AFAIR.  The version I was working
on was very similar to that first version.

> And Alex has leapfrogged to a modern C with SmallerC.

...

> I think I proffered that idea (start from scratch) to you at some
> point as an 'end around' moving small c (K&Rish) to an ANSI version.
> Maybe your recollection is different.

Well, I was working on a number of C parsers of my own designs, but
moved on to my own language.  It has a complete toolchain now, although
it's only developed to a very rudimentary level.

IIRC, I reworked the variant of SmallC to accept ANSI C style
declarations, addition of logical operators, and some other things.
So, structs were a big issue as I recall.


Rod Pemberton

-- 
Tolerance and socialism attracts intolerance and terrorism.  See:
France, United Kingdom, Germany, Denmark, Belgium, Netherlands, ...
UK: Strong encryption, non-issue. GR: Eurozone currency, priority.

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

#8373

>On Sat, 11 Jul 2015 12:57:42 -0400, s_dub...@yahoo.com  
><s_dub...@yahoo.com> wrote:
>
>> On Wednesday, July 8, 2015 at 2:52:36 AM UTC-5, Rod Pemberton wrote:
>>> On Wed, 08 Jul 2015 01:10:21 -0400, Alexei A. Frounze
>>> <alexf...@gmail.com> wrote:
>>> > On Tuesday, July 7, 2015 at 2:40:05 AM UTC-7, Rod Pemberton wrote:
>>> >> On Tue, 07 Jul 2015 04:44:33 -0400, Alexei A. Frounze
>>> >> <...@gmail.com> wrote:
>
>>> For a small C compiler, I was working with SmallC.  I still might
>>> again someday.  It only had a few areas that needed more development
>>> for use as a bootstrap compiler.
>>
>> Just to say, to me, a bootstrap compiler is a self-compiling compiler
>> that can be bootstrapped to a new OS architecture with a minimum of
>> fuss.  The 'minimum of fuss' means a hand full of IO interface functions
>> written in in-line assembler.  The usual strategy has the compiler
>> emitting assembler syntax for a presumed available assembler program
>> on the target OS.
>>
>> SmallC fits that, but for a subset of K&R C.  The 'subset' really means
>> that it is its own language,
>
>It's still C.
>
>Today, I only code in a subset of C, and that subset keeps getting smaller.
>Does that make my C code not C code anymore? ...
>
>> in the comp.sci sense.
>
>Huh?

The computer science sense of rigorous and formal treatment of languages.  Say
you have a language with the formal elements of '+' and '-', and then you add
the formal element of '*' for multiplication, those are treated as two
languages.  While the _set_ of formal elements are similar, they are not the
same, rigorously they are two different language sets.

In commoner daily speech we call your (terse) C as C, SmallC as (K&R) C, but
rigorously they are really not.


>> It can't handle 'struct', so it is more correct to call it something
>> like 'C subscript 0', or something,
>
>Yes, that's one serious deficiency, although it doesn't make SmallC  
>unuseable.
>

Agreed.  Plus we know the work around is to use adjacent arrays.

>> so as not to confuse its capabilities with a full K&R C compiler.  I have
>> seen versions for the Z80 which have advanced smallc from C_sub_0 to  
>> nearly
>> C_sub_K&R, which represent perhaps dozens of sub languages in-between to
>> get there.
>
>Ok.
>
>> It is an art to do a small modification to a compiler to implement a new
>> parsing capability to cover more of the full language syntax.  This can
>> only be done in steps so the existing compiler can handle it, and yet
>> produce a new superset compiler.  It ends up that C0 can build C1, C1 can
>> build C2, but C0 cannot parse C2.
>
>...
>
>>>  Unfortunately, Steve, who helped
>>> out a lot, chose a different path from the version I was working on.
>>>
>>
>> I know you were working on parsing 'void'.
>> Perhaps you could explain "chose a different path", and "unfortunately".
>
>"chose a different path"
>
>At some point, you decided to rewrite the compiler your own way.  I was
>using SmallC source from a number of existing SmallC variants.  So, you
>changes and direction won't work with the older/original code.  E.g., one
>SmallC variant has structs, but that author also made other modifications
>that weren't compatible with the earlier source.  The changes for struct
>couldn't just be added to the earlier code.
>

AIR the changes weren't that major, AIR I changed a number of function names,
added a few binary operators, changed the length of symbols for storage in
the symbol table, which changed its size, segmented .code from .data to allow
further development of the compiler beyond a 64k footprint.  It proves my
point earlier that: 'but C_sub_0 cannot parse C_sub_2'.  And I'm referring to
'self compiling compilers', and their incremental improvements to handle more
elements of the final language standard.  Cross compiling with a full featured
compiler to begin with is a different matter.

>"unfortunately"
>
>The CP/M stdio library of yours allowed me to compile and work on it.
>(IIRC, the NASM source helped to get it there too.)  Later on you
>developed a DOS I/O routines which worked with your code, but not with
>the earliest SmallC you started with, AFAIR.  The version I was working
>on was very similar to that first version.

The DOS interface library to int 21h was a poor hack meant more as an
example, a comparison to the Call5 library, showing the minimal functions
needed to port the smallc compiler to another OS.  I never really used it.
AIR the DOS io library took about 4 minutes to compile smallc.  The getc()
didn't match well to the DOS primitive, fetching one character at a time
from a buffered stream seemed to be the problem.  I think each character
fetch caused DOS to re-buffer the stream.  Improvements were left as an
exercise to the explorer.

>
>> And Alex has leapfrogged to a modern C with SmallerC.
>
>...
>
>> I think I proffered that idea (start from scratch) to you at some
>> point as an 'end around' moving small c (K&Rish) to an ANSI version.
>> Maybe your recollection is different.
>
>Well, I was working on a number of C parsers of my own designs, but
>moved on to my own language.  It has a complete toolchain now, although
>it's only developed to a very rudimentary level.
>
>IIRC, I reworked the variant of SmallC to accept ANSI C style
>declarations, addition of logical operators, and some other things.
>So, structs were a big issue as I recall.

Yes, SmallC falls alittle short, yet with its origins on the 8080/Z80 with
about 61k to work with for both the compiler and user's source program, it
is a note-able feat. -and a single pass compiler at that.

Steve

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

#8378

On Tue, 14 Jul 2015 10:39:03 -0400, s_dubrovich@yahoo.com  
<s_dubrovich@yahoo.com> wrote:
> Rod Pemberton ...
>> On Sat, 11 Jul 2015 12:57:42 -0400, s_dub...@yahoo.com
>> <s_dub...@yahoo.com> wrote:

>>> SmallC fits that, but for a subset of K&R C.  The 'subset' really means
>>> that it is its own language,
>>
>> It's still C.
>>
>> Today, I only code in a subset of C, and that subset keeps getting  
>> smaller.
>> Does that make my C code not C code anymore? ...
>>
>>> in the comp.sci sense.
>>
>> Huh?
>
> The computer science sense

I thought you meant a Usenet group or hierarchy by 'comp.sci',
but you didn't specify any particular group.  LOL.  So, that's
a language ambiguity due to terseness of expression ...  ;-)

> The computer science sense of rigorous and formal treatment of
> languages.  Say you have a language with the formal elements of
> '+' and '-', and then you add the formal element of '*' for
> multiplication, those are treated as two languages.  While the
> _set_ of formal elements are similar, they are not the same,
> rigorously they are two different language sets.

Yes, James asks many questions on topics like this on comp.lang.misc.
I don't recall seeing you there.

> In commoner daily speech we call your (terse) C as C, SmallC as
> (K&R) C, but rigorously they are really not.

Ok.


Rod Pemberton

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | alt.os.development

csiph-web