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

Groups > comp.os.msdos.programmer > #1086 > unrolled thread

Smaller C compiler

Back to article view | Back to comp.os.msdos.programmer

Contents

  Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-01 08:15 -0800
    Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-01 18:42 +0000
      Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-01 19:14 -0800
        Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-02 11:13 +0000
          Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-02 03:21 -0800
            Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-03 06:21 +0000
              Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-02 23:17 -0800
                Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-03 13:31 +0000
                  Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-03 06:05 -0800
                  Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-03 10:47 -0500
                    Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-03 21:18 -0800
    Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-03 12:23 -0500
      Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-03 16:26 -0500
        Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-03 23:58 -0800
          Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-04 04:31 -0500
            Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-04 05:01 -0500
              Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-04 02:20 -0800
                Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-05 06:33 -0500
                  Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-05 21:37 -0800
                    Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-06 12:19 -0500
                      Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-06 22:23 -0800
                        Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-07 13:48 -0500
                          Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-07 16:34 -0800
                            Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-08 02:12 -0500
                              Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-13 03:32 -0800
                                Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-15 04:47 -0500
                                  Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-15 02:14 -0800
                                    Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-15 13:21 -0500
            Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-04 23:39 -0800
              Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-05 06:38 -0500
                Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-05 21:40 -0800
                Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-06 04:19 -0800
                  Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-06 13:40 -0500
                  Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-14 21:07 -0800
      Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-03 22:22 -0800
        Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-04 04:30 -0500
          Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-04 23:21 -0800
            Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-05 04:23 -0500
              Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-05 21:31 -0800
    Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-10 04:59 +0000
      Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-10 06:17 +0000
        Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-11 02:36 -0800
          Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-11 13:44 +0000
    Re: Smaller C compiler Harry Potter <rose.joseph12@yahoo.com> - 2013-12-10 10:41 -0800
      Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-11 03:06 -0800
        Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-11 10:47 -0500
          Re: Smaller C compiler Harry Potter <rose.joseph12@yahoo.com> - 2013-12-11 08:01 -0800
            Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-11 13:40 -0500
          Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-11 22:07 -0800
          Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-25 02:33 -0800
            Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-29 03:24 -0800
    Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-21 15:55 -0800
    Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-29 17:16 +0000
      Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-29 21:54 -0500
        Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-29 19:38 -0800
      Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-29 19:36 -0800
        Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-30 05:07 +0000
          Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-29 21:58 -0800
          Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-01-05 19:43 -0800
            Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2014-01-06 15:27 +0000
              Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-06 19:51 -0500
                Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2014-01-07 04:27 +0000
                  Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-01-06 21:52 -0800
            Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-02-16 22:57 -0800
              Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-02-25 00:17 -0800
                Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-03-01 21:31 -0800
                  Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-03-10 01:46 -0700
                    Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-04-20 20:19 -0700
                      Re: Smaller C compiler Harry Potter <rose.joseph12@yahoo.com> - 2014-04-23 11:20 -0700
                        Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-04-23 11:41 -0700
                          Re: Smaller C compiler Harry Potter <rose.joseph12@yahoo.com> - 2014-04-25 06:08 -0700
                      Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-09-14 03:06 -0700
                        Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-11-09 03:26 -0800
                          Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-11-28 04:06 -0800
                            Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-12-21 01:56 -0800
                              Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-01-10 10:37 -0800
                                Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-04-19 23:55 -0700
                                  Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2015-04-22 06:13 +0000
                                    Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-04-22 00:12 -0700
                                  Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-04-25 21:11 -0700
                                    Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-05-16 17:49 -0700
                                      Re: Smaller C compiler "Bill Buckels" <bbuckels@mts.net> - 2015-05-19 20:01 -0500
                                        Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-05-19 18:18 -0700
                                      Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-08-15 02:13 -0700
                                        Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-06 15:55 -0700

Page 1 of 5  [1] 2 3 4 5  Next page →

#1086 — Smaller C compiler

In case this is of interest to anyone, I'm working on a small and simple C compiler currently targeting x86 (and MIPS:), Smaller C.

There's a discussion on alt.os.development, where I first announced the compiler: https://groups.google.com/d/topic/alt.os.development/-fP1ZLxGgFk/discussion. Perhaps, there are interested souls on comp.os.msdos.programmer as well, hence this post here.

Smaller C in not too many words:
- is much like the original Small C by Cain/Hendrix/etc and Micro-C by Dunfield, but with normal ANSI/C89 syntax and behavior (=no foul play in expressions as in Micro-C)
- generates NASM-agreeable 16- or 32-bit non-segmented assembly code (e.g. tiny and small memory models) and should be fairly easy adaptable to other assemblers if needed
- can compile its own code, and, apparently, self-compiled code works too
- is trivially compilable with any C89+ compiler (Turbo/Borland C/C++, Open Watcom C/C++, djgpp, gcc, you name it) and can run in DOS (it's small enough for the small memory model)
- doesn't have its own libc, though it should be easy to implement a basic library for DOS (the compiler itself needs only a handful of ctype/string/clib/stdio functions to operate)
- BSD licensed
The rest is in the documentation and code (links follow below).

I'm making improvements (a few are baking right now) and hoping to add struct support in December/January.

The code (with a few test apps) is at: https://github.com/alexfru/SmallerC (look under v0100).

Documentation (live): https://github.com/alexfru/SmallerC/wiki/Smaller-C-Wiki

Opinions?

Testers/test-drivers? ;)

Thanks,
Alex

[toc] | [next] | [standalone]

#1088

Alexei A. Frounze wrote:

> In case this is of interest to anyone, I'm working on a small and simple
> C compiler currently targeting x86 (and MIPS:), Smaller C.
[snip]
> Opinions?
>
> Testers/test-drivers? ;)

Success compiling with Fabrice Bellard's Tiny CC (Win32):
  http://bellard.org/tcc/

Unfortunately, tcc is an all-in-one program (no external linker), and I don't 
currently have another C compiler installed, so I can't finish the compile 
with Smaller C itself -- I get to the point where nasm has generated the .obj 
file, and that's it. Shrug.

-- 
You must learn to control your strength.

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

#1089

On Sunday, December 1, 2013 10:42:36 AM UTC-8, Auric__ wrote:
> Alexei A. Frounze wrote:
> 
> > In case this is of interest to anyone, I'm working on a small and simple
> > C compiler currently targeting x86 (and MIPS:), Smaller C.
> [snip]
> > Opinions?
> >
> > Testers/test-drivers? ;)
> 
> Success compiling with Fabrice Bellard's Tiny CC (Win32):
>   http://bellard.org/tcc/
> 
> Unfortunately, tcc is an all-in-one program (no external linker), and I don't 
> currently have another C compiler installed, so I can't finish the compile 
> with Smaller C itself -- I get to the point where nasm has generated the .obj 
> file, and that's it. Shrug.
> 

You can use either Turbo C++ 1.01 (in DOS, Windows or DosBox) or DJGPP/gcc (ditto) or 32-bit MinGW/gcc (in Windows) or plain 32-bit gcc (in Linux) to make an executable out of the smlrc.obj or smlrc.o file and use that compiler's libc/etc.

Alex

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

#1090

Alexei A. Frounze wrote:

> On Sunday, December 1, 2013 10:42:36 AM UTC-8, Auric__ wrote:
>> Alexei A. Frounze wrote:
>>
>> > In case this is of interest to anyone, I'm working on a small and
>> > simple C compiler currently targeting x86 (and MIPS:), Smaller C.
>> [snip]
>> > Opinions?
>> >
>> > Testers/test-drivers? ;)
>>
>> Success compiling with Fabrice Bellard's Tiny CC (Win32):
>>   http://bellard.org/tcc/
>>
>> Unfortunately, tcc is an all-in-one program (no external linker), and I
>> don't currently have another C compiler installed, so I can't finish
>> the compile with Smaller C itself -- I get to the point where nasm has
>> generated the .obj file, and that's it. Shrug.
>
> You can use either Turbo C++ 1.01 (in DOS, Windows or DosBox) or
> DJGPP/gcc (ditto) or 32-bit MinGW/gcc (in Windows) or plain 32-bit gcc
> (in Linux) to make an executable out of the smlrc.obj or smlrc.o file
> and use that compiler's libc/etc.

Yes, I know, I just don't have any of those installed. (Well... gcc on the 
Linux server... meh.) My main point was to add another success story (sorta) 
to your list.

In the next day or so I intend to install lcc-win64; results when and if. I 
might also try under Visual C++, if I can find my copy. (Don't hold your 
breath, though.)

-- 
She likes that word "chaos." It defines everything on the outside.

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

#1091

On Monday, December 2, 2013 3:13:39 AM UTC-8, Auric__ wrote:
> Alexei A. Frounze wrote:
> 
> > On Sunday, December 1, 2013 10:42:36 AM UTC-8, Auric__ wrote:
> >> Alexei A. Frounze wrote:
> >>
> >> > In case this is of interest to anyone, I'm working on a small and
> >> > simple C compiler currently targeting x86 (and MIPS:), Smaller C.
> >> [snip]
> >> > Opinions?
> >> >
> >> > Testers/test-drivers? ;)
> >>
> >> Success compiling with Fabrice Bellard's Tiny CC (Win32):
> >>   http://bellard.org/tcc/
> >>
> >> Unfortunately, tcc is an all-in-one program (no external linker), and I
> >> don't currently have another C compiler installed, so I can't finish
> >> the compile with Smaller C itself -- I get to the point where nasm has
> >> generated the .obj file, and that's it. Shrug.
> >
> > You can use either Turbo C++ 1.01 (in DOS, Windows or DosBox) or
> > DJGPP/gcc (ditto) or 32-bit MinGW/gcc (in Windows) or plain 32-bit gcc
> > (in Linux) to make an executable out of the smlrc.obj or smlrc.o file
> > and use that compiler's libc/etc.
> 
> Yes, I know, I just don't have any of those installed. (Well... gcc on the 
> Linux server... meh.) My main point was to add another success story (sorta) 
> to your list.
> 
> In the next day or so I intend to install lcc-win64; results when and if. I 
> might also try under Visual C++, if I can find my copy. (Don't hold your 
> breath, though.)

I hope lcc-win64 supports 32-bit platforms (you'll need the 32-bit variant of libc and a 32-bit linker) and the stack-based calling convention.

Alex

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

#1092

Alexei A. Frounze wrote:

> On Monday, December 2, 2013 3:13:39 AM UTC-8, Auric__ wrote:
[snip]
>> In the next day or so I intend to install lcc-win64; results when and
>> if. I might also try under Visual C++, if I can find my copy. (Don't
>> hold your breath, though.)
>
> I hope lcc-win64 supports 32-bit platforms (you'll need the 32-bit
> variant of libc and a 32-bit linker) and the stack-based calling
> convention.

It does, and it includes the 32-bit version as well, so I tested both. They 
work equally well, as far as creating smrlc.exe goes, but you need to stick 
with the 32-bit linker for apps compiled via smrlc.exe.

Compiling Smaller C via lcc:

  lc.exe smlrc.c

...and that's it. Using lcc's linker for Smaller C apps:

  smlrc.exe -seg32 smlrc.c smlrc.asm
  nasm.exe smlrc.asm
  lcclnk.exe smlrc.obj

...and there you go. Unfortunately, when I tried doing this to your test.c 
and snake.c, neither worked, possibly due to the inline asm. (They both fail 
in lcc and tcc as well.)

So I tried my own test.c:

  int main() {
    printf("\n---insert standard test message here---\n");
  }

(I noticed that the wiki says most preprocessor directives don't work, so 
didn't use #include.) Results:

  smlrc.exe -seg32 test.c test.asm
  nasm.exe -f win32 test.asm
  lcclnk.exe test.obj
  test.exe

  ---insert standard test message here---

So the compiler *does* work. ;-)

-- 
Squeaky wheel gets the kick!

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

#1093

On Monday, December 2, 2013 10:21:41 PM UTC-8, Auric__ wrote:
> Alexei A. Frounze wrote:
> 
> > On Monday, December 2, 2013 3:13:39 AM UTC-8, Auric__ wrote:
> [snip]
> >> In the next day or so I intend to install lcc-win64; results when and
> >> if. I might also try under Visual C++, if I can find my copy. (Don't
> >> hold your breath, though.)
> >
> > I hope lcc-win64 supports 32-bit platforms (you'll need the 32-bit
> > variant of libc and a 32-bit linker) and the stack-based calling
> > convention.
> 
> It does, and it includes the 32-bit version as well, so I tested both. They 
> work equally well, as far as creating smrlc.exe goes, but you need to stick 
> with the 32-bit linker for apps compiled via smrlc.exe.
> 
> Compiling Smaller C via lcc:
> 
>   lc.exe smlrc.c
> 
> ...and that's it. Using lcc's linker for Smaller C apps:
> 
>   smlrc.exe -seg32 smlrc.c smlrc.asm
>   nasm.exe smlrc.asm
>   lcclnk.exe smlrc.obj
> 
> ...and there you go. Unfortunately, when I tried doing this to your test.c 
> and snake.c, neither worked, possibly due to the inline asm. (They both fail 
> in lcc and tcc as well.)
> 
> So I tried my own test.c:
> 
>   int main() {
>     printf("\n---insert standard test message here---\n");
>   }
> 
> (I noticed that the wiki says most preprocessor directives don't work, so 
> didn't use #include.) Results:
> 
>   smlrc.exe -seg32 test.c test.asm
>   nasm.exe -f win32 test.asm
>   lcclnk.exe test.obj
>   test.exe
> 
>   ---insert standard test message here---
> 
> So the compiler *does* work. ;-)

Awesome, thanks!

The reason why test.c and snake.c didn't compile is in that they are supposed to be compiled:
1. as 16-bit DOS .COM applications
2. by NASM directly into the executable

Both begin with the following text outlining how they should be compiled and run:

/*
  Compile:
    smlrc -flat16 snake.c snake.asm
    nasm -f bin snake.asm -o snake.com

  Run snake.com in DOS, 32-bit Windows or DosBox.
*/

asm("org 0x100");

Even if you succeeded in assembling the two resulting asm files into non-raw-binary formats (e.g. into OMF/COFF/whatever .obj), the 16-bit code and "org 0x100" would then throw off most 32-bit linkers, they just don't expect such input.

These two test apps are supposed to be compiled as outlined, not with other compilers or assemblers. Their inline assembly goes unmodified to smlrc's output and gets consumed by NASM. That's a cheap way to support inline assembly and there doesn't seem anything else in the inline asm of the two apps that would prevent assembly/linking of them. But, even if successfully compiled, clearly, they would stand no chance of functioning as Win32 or native Linux apps as they expect to run in 16-bit mode, use the DOS/BIOS service interrupts for keyboard input, setting video mode, and access physical memory.

As for #include, you can use it, it's supported (you can find #include "cgx86.c" inside smlrc.c), but you'll have to provide some include file of yours as there's no standard library coming with the compiler as of yet (no stdio.h, etc).

Thanks again!

HTH,
Alex

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

#1094

Alexei A. Frounze wrote:

[snip]
> The reason why test.c and snake.c didn't compile is in that they are
> supposed to be compiled: 1. as 16-bit DOS .COM applications
> 2. by NASM directly into the executable
>
> Both begin with the following text outlining how they should be compiled
> and run:
>
> /*
>   Compile:
>     smlrc -flat16 snake.c snake.asm
>     nasm -f bin snake.asm -o snake.com
>
>   Run snake.com in DOS, 32-bit Windows or DosBox.
> */
>
> asm("org 0x100");

Hm... not sure how I managed to not see that last night. Guess I was more 
tired than I thought.

[snip]
> As for #include, you can use it, it's supported (you can find #include
> "cgx86.c" inside smlrc.c), but you'll have to provide some include file
> of yours as there's no standard library coming with the compiler as of
> yet (no stdio.h, etc). 

Yeah, I noticed that. I *strongly* recommend moving your implementation of 
stdlib functions out of the compiler ASAP. The further you get with this 
project, the more of a PITA it will be to do so down the road.

> Thanks again!

Np.

-- 
It would appear the threat was vastly overrated.

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

#1095

On Tuesday, December 3, 2013 5:31:18 AM UTC-8, Auric__ wrote:
> Alexei A. Frounze wrote:
> 
> [snip]
> > The reason why test.c and snake.c didn't compile is in that they are
> > supposed to be compiled: 1. as 16-bit DOS .COM applications
> > 2. by NASM directly into the executable
> >
> > Both begin with the following text outlining how they should be compiled
> > and run:
> >
> > /*
> >   Compile:
> >     smlrc -flat16 snake.c snake.asm
> >     nasm -f bin snake.asm -o snake.com
> >
> >   Run snake.com in DOS, 32-bit Windows or DosBox.
> > */
> >
> > asm("org 0x100");
> 
> Hm... not sure how I managed to not see that last night. Guess I was more 
> tired than I thought.

It happens.

> [snip]
> > As for #include, you can use it, it's supported (you can find #include
> > "cgx86.c" inside smlrc.c), but you'll have to provide some include file
> > of yours as there's no standard library coming with the compiler as of
> > yet (no stdio.h, etc). 
> 
> Yeah, I noticed that. I *strongly* recommend moving your implementation of 
> stdlib functions out of the compiler ASAP. The further you get with this 
> project, the more of a PITA it will be to do so down the road.

My compiler does not implement standard C functions inside of itself. It's just that either none are used (as in the two test programs, test.c and snake.c) and it's not a problem or you supply yours (looks like in your case lcc's linker conveniently linked lcc's standard library to smlrc.obj to produce the executable) and it's not a problem again. The only problem is when you don't have the standard library at all but need it.

Alex

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

#1097

On Tue, 03 Dec 2013 08:31:18 -0500, Auric__ <not.my.real@email.address>  
wrote:
> Alexei A. Frounze wrote:

>> [snip]
>> As for #include, you can use it, it's supported (you can find #include
>> "cgx86.c" inside smlrc.c), but you'll have to provide some include file
>> of yours as there's no standard library coming with the compiler as of
>> yet (no stdio.h, etc).
>
> Yeah, I noticed that. I *strongly* recommend moving your implementation  
> of stdlib functions out of the compiler ASAP. The further you get with
> this project, the more of a PITA it will be to do so down the road.
>

No...

Alexei probably needs some C library functions to be internal in order
to bootstrap the C compiler when no C library is present.  That's typical
of any C compiler that can bootstrap itself completely, even GNU's GCC.

I frequently code some of my programs to only use ANSI C without a
C library, or ANSI C and only <stdio.h> when I need features like
memory allocation (using file I/O...).  In which case, I'll need a
few functions from the "missing" C libraries implemented internally.
The most common other one IMO would be <string.h>.  You really don't
need the remainder of the C library, if you know what you're doing.

A better solution would be to make the functions conditionally included
if Alexei has enough preprocessor support in his Smaller C compiler:

#define STDIOH
#ifddef STDIOH
#include <stdio.h>
#else
... stdio.h functions
#endif

Or, if only rudimentary preprocessor support is available:

/* stdio.h */
#if 1
/* disable here, enable below to bootstrap */
#include <stdio.h>
#include <string.h>
#endif

/* stdio.h bootstrap functions */
/* string.h bootstrap functions */
#if 0
... stdio.h bootstrap functions ...
... string.h bootstrap functions ...
#endif

FYI, if you remember Alexei, Steve Dubrovich wrote a file I/O library
for his updates to and modified verion of Ron Cain's Small C.
He wrote both a CP/M version for for DOS, and an Int 21h version.
They're on his website in his various projects:

http://www.project-fbin.hostoi.com/index.htm

I used the CP/M version for my modifications to Ron Cain's Small C.
It worked just fine in a Windows SE DOS console window, but I couldn't
get it to work properly in real-mode MS-DOS v7.10.  The Int 21h version
was setup differently, more for Steve's variant than for Ron Cain's
original version.  So, I haven't used it.


Rod Pemberton

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

#1102

On Tuesday, December 3, 2013 7:47:42 AM UTC-8, Rod Pemberton wrote:
> On Tue, 03 Dec 2013 08:31:18 -0500, Auric__ <not.my.real@email.address>  
> wrote:

[snip]

> No...
> 
> Alexei probably needs some C library functions to be internal in order
> to bootstrap the C compiler when no C library is present.  That's typical
> of any C compiler that can bootstrap itself completely, even GNU's GCC.
> 
> I frequently code some of my programs to only use ANSI C without a
> C library, or ANSI C and only <stdio.h> when I need features like
> memory allocation (using file I/O...).  In which case, I'll need a
> few functions from the "missing" C libraries implemented internally.
> The most common other one IMO would be <string.h>.  You really don't
> need the remainder of the C library, if you know what you're doing.
> 
> A better solution would be to make the functions conditionally included
> if Alexei has enough preprocessor support in his Smaller C compiler:
> 
> #define STDIOH
> #ifddef STDIOH
> #include <stdio.h>
> #else
> ... stdio.h functions
> #endif
> 
> Or, if only rudimentary preprocessor support is available:
> 
> /* stdio.h */
> #if 1
> /* disable here, enable below to bootstrap */
> #include <stdio.h>
> #include <string.h>
> #endif
> 
> /* stdio.h bootstrap functions */
> /* string.h bootstrap functions */
> #if 0
> ... stdio.h bootstrap functions ...
> ... string.h bootstrap functions ...
> #endif

I already use conditional inclusion. If the macro __SMALLER_C__ isn't defined, standard C include files are included and things like va_arg, va_list, etc from them are used. If the macro __SMALLER_C__ is defined (the bootstrapping/self-compiling case), then instead of the inclusion of those files the compiler declares the standard library functions as extern and accesses the optional on-stack function arguments directly.

> FYI, if you remember Alexei, Steve Dubrovich wrote a file I/O library
> for his updates to and modified verion of Ron Cain's Small C.
> He wrote both a CP/M version for for DOS, and an Int 21h version.
> They're on his website in his various projects:
> 
> http://www.project-fbin.hostoi.com/index.htm

I've seen that, thanks. For bootstrapping I have all the needed functions implemented on top of open(), close(), read() and write(). Those 4 functions and exit() trivially translate to the appropriate system calls.

> I used the CP/M version for my modifications to Ron Cain's Small C.
> It worked just fine in a Windows SE DOS console window, but I couldn't
> get it to work properly in real-mode MS-DOS v7.10.  The Int 21h version
> was setup differently, more for Steve's variant than for Ron Cain's
> original version.  So, I haven't used it.

I have no plans to support CP/M interfaces/APIs. In 16-bit mode I'm targeting real-mode DOS. I'm using DosBox to run the 16-bit version of the compiler. I also have access to WinXP and 32-bit Win7 (just haven't used them for running the 16-bit compiler yet).

Alex

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

#1098

On Sun, 01 Dec 2013 11:15:37 -0500, Alexei A. Frounze  
<alexfrunews@gmail.com> wrote:

> [snip]
> - doesn't have its own libc, though it should be easy to implement a  
> basic library for DOS (the compiler itself needs only a handful of  
> ctype/string/clib/stdio functions to operate)

I mentioned Steve's I/O routines in the other post with a link
to his website.  It looks like you may be using far more C library
functions than he implemented, but you can whittle down or eliminate
a bunch of them.

> Opinions?

Auric mentioned your included functions.  It's
possible to reduce the quantity used, or implement them
internally for bootstrapping.  That may have a negative
impact on speed though.

exit -> suggested to rework to use return()
atoi -> obsolete
-usually strtod(), strtol(), strtoul() are recommended
-sscanf() or fscanf() can also be used

strlen
strcpy
strchr
strcmp
strncmp -> can usually be converted to strcmp(),
-if you terminate '\0' the strings at 'n'
memmove -> usually can be changed to use memcpy()
memcpy
memset

Most of the str*() functions and mem*() functions
are easy to implement.  Most are just loops with one
simple operation and/or a check for the '\0' null
terminator.  You could also used reduced versions
with less than normal functionality, e.g., for strcmp().
Comparing for equal or not equal is much simpler than
producing -1/false, 0, and 1/true.  If you use files
instead of memory, you can eliminate most of these also.

isspace
isdigit
isalpha
isalnum

If you desire, you can replace is*() functions by using
strchr() or strrchr() with a string, or a 128 or 256 char
arrays as a lookup table, or even use character based
procedures, e.g., with a switch(c) or even if()'s.

fopen -> keep it.
fclose -> keep it.
putchar -> can use fputc to stdout
fputc -> keep it.
fgetc -> keep it.
puts -> can use fprintf() to stdout with '\n'
fputs -> can use fprintf() with '\n'
sprintf -> sometimes can rework for printf() or fprintf()
printf -> can use fprintf() to stdin or stdout
fprintf -> keep it.

It's hard to eliminate sprintf() and fprintf() when you
need the formatting options.  They are also long and
complicated routines.  puts(), of course, is faster.
However, with some work, you can usually eliminate all
internal code that uses memory by preferencing file
I/O functions.  So, you can eliminate sprintf(), sscanf(),
in favor of fprintf(), fscanf(), etc.  Some compilers
implement tmpfile() as a memory file.  That can provide
a large speed boost.  You effectively get random access
memory - as a file - with convenient to use functions.

vsprintf()
vprintf()
vfprintf()

I've not use v*printf() functions much.  So, it should be
possible to eliminate these by using other printf functions,
depending on what you're using them for.  If you're using
them to handle variadic argument lists, then you could use
a stack.

> Testers/test-drivers? ;)

That's coming up next...  I was going to try compiling it
with DJGPP, perhaps OpenWatcom.  I'll probably need to
review Aurics post to figure out how to link it.

It has C++ style comments, so I'm wondering about warnings:

gcc -Wall -ansi -pedantic
wcl/l=dos -wx
wcl386/l=dos4g -wx


Rod Pemberton

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

#1099

On Tue, 03 Dec 2013 12:23:45 -0500, Rod Pemberton  
<dont_use_email@xnohavenotit.cnm> wrote:
> On Sun, 01 Dec 2013 11:15:37 -0500, Alexei A. Frounze  
> <alexfrunews@gmail.com> wrote:

>> Opinions?
>
> [snip]

Opinion set #2:

The readme.txt file seems to have LF's while the
license.txt file seems to have CRLF's.  DOS needs
CRLF's.

The DOS environment I'm using no longer is able
to access the internet.  So, I would've preferred
the build information in the .zip, instead of a
link to the website.  If the website changes or
goes offline in the future, the .zip doesn't have
any instructions.

I'd suggest a simple cleaned up text only version
of the following sections on the Wiki as build.txt
in the .zip:

   How do I compile Smaller C on/for x86?
   How do I compile Smaller C for MIPS?
   How do I run Smaller C?
   How do I compile Smaller C with itself?

The "options" section of the run section could
be omitted, optionally.

A note that cgx86.c and cgmips.c are included by
smlrc.c for those confused about why neither are
mentioned in the wiki build instructions would
be nice.

>> Testers/test-drivers? ;)
>
> That's coming up next...  I was going to try compiling it
> with DJGPP, perhaps OpenWatcom.

The code does NOT like the '-ansi' GCC option...
'-pedantic' and '-Wall' are fine.

NASM 0.98.39 has thousands of these errors:

   smlrcdj.asm:<line #>: error: short jump is out of range

I have a number of other versions of NASM.  The next
oldest is 2.06rc8.  It and all other more recent versions
compile the .o without warnings.  These errors can be
fixed for all versions of NASM by adding a 'near' keyword
for conditional jumps or branches.  E.g.,

   jne   LXXXX

becomes

   jne   near LXXXX

I'm not sure if that causes problems with the other
supported assemblers or not.  Support for 0.98.39
would be nice though.

There is a line which tells how to compile
with OpenWatcom.  However, the section for how to
compile Smaller C with itself has nothing for
OpenWatcom...

For 16-bit OpenWatcom:

   wcl/l=dos -wx smlrc.c
   smlrc -seg16 smlrc.c smlrc.asm
   nasm -f obj -o smlrc.obj smlrc.asm

That seems to work.  I'm not sure what the wlink
line is for OpenWatcom.  I've been trying this
which fails to link:

   wlink system dos name smlrc.exe file smlrc.obj

For 32-bit OpenWatcom, this gives an error:

   wcl386/l=dos4g -wx smlrc.c
   smlrc -seg32 smlrc.c smlrc.asm

  Error in "smlrc.c" (383:36)
  Constant too big for 32-bit type

So, I didn't make it to nasm on that one.

I tried adding -unsigned-char but it still has the
same error.  -flat32 errors also the same.

I'm assuming that's line 383 position 36.  If so,
thats '+':

   char TokenIdentName[MAX_IDENT_LEN + 1];

where MAX_IDENT_LEN is #defined as 31.

HTH,


Rod Pemberton

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

#1104

On Tuesday, December 3, 2013 1:26:27 PM UTC-8, Rod Pemberton wrote:
> On Tue, 03 Dec 2013 12:23:45 -0500, Rod Pemberton  
> <dont_use_email@xnohavenotit.cnm> wrote:
> > On Sun, 01 Dec 2013 11:15:37 -0500, Alexei A. Frounze  
> > <...@gmail.com> wrote:
> 
> >> Opinions?
> >
> > [snip]
> 
> Opinion set #2:
> 
> The readme.txt file seems to have LF's while the
> license.txt file seems to have CRLF's.  DOS needs
> CRLF's.

readme.txt was created on github. You can blame github for not providing an option. :)

> The DOS environment I'm using no longer is able
> to access the internet.  So, I would've preferred
> the build information in the .zip, instead of a
> link to the website.  If the website changes or
> goes offline in the future, the .zip doesn't have
> any instructions.

The .zip file you're talking about is created automatically by github. You can blame github for not putting the wiki files into the .zip. :)

> I'd suggest a simple cleaned up text only version
> of the following sections on the Wiki as build.txt
> in the .zip:
> 
>    How do I compile Smaller C on/for x86?
>    How do I compile Smaller C for MIPS?
>    How do I run Smaller C?
>    How do I compile Smaller C with itself?
> 
> The "options" section of the run section could
> be omitted, optionally.

I'll probably do that when I'm mostly done with v1.xx (pending commits + casts + struct + a few extras, perhaps). Until then I don't want to spend time updating the text in two places.

> A note that cgx86.c and cgmips.c are included by
> smlrc.c for those confused about why neither are
> mentioned in the wiki build instructions would
> be nice.

And the directory structure should be changed (separate compiler from tests from binaries from whatnot).

> >> Testers/test-drivers? ;)
> >
> > That's coming up next...  I was going to try compiling it
> > with DJGPP, perhaps OpenWatcom.
> 
> The code does NOT like the '-ansi' GCC option...
> '-pedantic' and '-Wall' are fine.

That's expected w.r.t. C++ style comments (and variable declarations intermixed with statements, C99/C++ style).

> NASM 0.98.39 has thousands of these errors:
> 
>    smlrcdj.asm:<line #>: error: short jump is out of range

Perhaps, that old NASM by default tries to make all jumps short (=with 8-bit relative address). The newer ones don't do that and they by default optimize the jump sizes.

> I have a number of other versions of NASM.  The next
> oldest is 2.06rc8.  It and all other more recent versions
> compile the .o without warnings.  These errors can be
> fixed for all versions of NASM by adding a 'near' keyword
> for conditional jumps or branches.  E.g.,
> 
>    jne   LXXXX
> 
> becomes
> 
>    jne   near LXXXX

I don't think I want to do anything here. If 'near' causes NASM to always generate jumps with 16(32)-bit relative addresses, smlrc won't be able to compile itself. Currently, the 16-bit executable is ~60K of self-compiled code. And there are several thousands of jumps in self-compiled smlrc.c. One extra byte per jump costs on the order of several KB of code size. I'd rather let NASM optimize this.

> I'm not sure if that causes problems with the other
> supported assemblers or not.  Support for 0.98.39
> would be nice though.

Was never anticipated or planned.

> There is a line which tells how to compile
> with OpenWatcom.  However, the section for how to
> compile Smaller C with itself has nothing for
> OpenWatcom...

I've never tried linking the 16-bit self-compiled smlrc with the 16-bit OW startup and library code.

> For 16-bit OpenWatcom:
> 
>    wcl/l=dos -wx smlrc.c
>    smlrc -seg16 smlrc.c smlrc.asm
>    nasm -f obj -o smlrc.obj smlrc.asm
> 
> That seems to work.  I'm not sure what the wlink
> line is for OpenWatcom.  I've been trying this
> which fails to link:
> 
>    wlink system dos name smlrc.exe file smlrc.obj

It looks like it won't work like that. smlrc-generated code expects what's known as __cdecl in OW. OTOH, OW's stnadard libary functions appear to be __watcall. The difference is in underscoring of symbols and in how parameters are passed. Would you like to research this further?

> For 32-bit OpenWatcom, this gives an error:
> 
>    wcl386/l=dos4g -wx smlrc.c
>    smlrc -seg32 smlrc.c smlrc.asm
> 
>   Error in "smlrc.c" (383:36)
>   Constant too big for 32-bit type

I'm not sure how you got that one. I used Win32 wcl386 to create a 4G .exe. Then I ran it with -seg32 in DosBox and the compilation succeeded.

Was your wcl386 itself a 4G .exe? What version of OW did you use? Mine's 1.9.

Also, I'm routinely using OW to create Win32 versions of smlrc. I've never seen anything like this when self-compiling smlrc, 16-bit or 32-bit.

> So, I didn't make it to nasm on that one.
> I tried adding -unsigned-char but it still has the
> same error.  -flat32 errors also the same.

Those options are unrelated (=unlikely to be relayed).

> I'm assuming that's line 383 position 36.  If so,
> thats '+':
> 
>    char TokenIdentName[MAX_IDENT_LEN + 1];
> 
> where MAX_IDENT_LEN is #defined as 31.

You get "Constant too big for N-bit type" for numeric constants that don't fit into 16 or 32 bits, whichever is the native int size of the compiled executable. 31 should fit in either. So, I don't know how you got here.

Had you got this instead (note the 16):

   Error in "smlrc.c" (383:36)
   Constant too big for 16-bit type

or better yet

   Error in "smlrc.c" (383:36)
   Non-constant expression

I'd have some ideas. But clearly, that should work if smlrc.exe itself is 32-bit.

Alex

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

#1106

On Wed, 04 Dec 2013 02:58:30 -0500, Alexei A. Frounze  
<alexfrunews@gmail.com> wrote:

> On Tuesday, December 3, 2013 1:26:27 PM UTC-8, Rod Pemberton wrote:
>> On Tue, 03 Dec 2013 12:23:45 -0500, Rod Pemberton
>> <dont_use_email@xnohavenotit.cnm> wrote:
>> > On Sun, 01 Dec 2013 11:15:37 -0500, Alexei A. Frounze

>> For 16-bit OpenWatcom:
>>
>>    wcl/l=dos -wx smlrc.c
>>    smlrc -seg16 smlrc.c smlrc.asm
>>    nasm -f obj -o smlrc.obj smlrc.asm
>>
>> That seems to work.  I'm not sure what the wlink
>> line is for OpenWatcom.  I've been trying this
>> which fails to link:
>>
>>    wlink system dos name smlrc.exe file smlrc.obj
>
> It looks like it won't work like that. smlrc-generated code expects  
> what's known as __cdecl in OW. OTOH, OW's stnadard libary functions  
> appear to be __watcall. The difference is in underscoring of symbols
> and in how parameters are passed.
...

> Would you like to research this further?

Would you? ;-)

Being able to link with OW would be nice.  It's not a necessity in
my book.  It just means whomever uses OpenWatcom needs an additional
linker from another source to link .obj's.  If a .com can be made
then no linker would be needed.  Or, perhaps a raw (no linker)
DOS exe via NASM as a .bin format could be generated...  IIRC,
Steve did something like this.  Off hand, I don't recall if you did
so too in your DOS code.  Since a single .obj file is produced,
then linking might not be required.  I'm thinking along the lines
of DJGPP's coff2exe and exe2coff utilities, but these would be
for obj's.  MS has exe2bin.  Is there a bin2exe?  If not, is
that a restriction of the OMF/OBJ object?  I.e., why can DJGPP
style COFF's go from COFF to EXE, but DOS style OMF/OBJ can't go
 from OMF/OBJ to EXE?  If there is a sound reason, then perhaps a
COFF object or ELF object could be used instead of OMF/OBJ? ...

http://www.delorie.com/djgpp/doc/utils/utils_toc.html

Didn't NASM have a way to link? I know NASM has it's own object
format called RDOFF.

>> For 32-bit OpenWatcom, this gives an error:
>>
>>    wcl386/l=dos4g -wx smlrc.c
>>    smlrc -seg32 smlrc.c smlrc.asm
>>
>>   Error in "smlrc.c" (383:36)
>>   Constant too big for 32-bit type
>
> I'm not sure how you got that one. I used Win32 wcl386 to create a 4G  
> .exe. Then I ran it with -seg32 in DosBox and the compilation succeeded.
>
> Was your wcl386 itself a 4G .exe?

I have no idea.  It's whatever came with the install.

> What version of OW did you use? Mine's 1.9.

It's version 1.3.  Do you think that's an issue?

> Also, I'm routinely using OW to create Win32 versions of smlrc. I've  
> never seen anything like this when self-compiling smlrc, 16-bit or  
> 32-bit.

What lines do you use to build those for OW?

I know there was some other options in the wiki for the first step
with OpenWatcom which I didn't try since I wasn't familiar with them.
I went with trying the command lines I use, perhaps that an issue?

>> I'm assuming that's line 383 position 36.  If so,
>> thats '+':
>>
>>    char TokenIdentName[MAX_IDENT_LEN + 1];
>>
>> where MAX_IDENT_LEN is #defined as 31.
>
> You get "Constant too big for N-bit type" for numeric constants that  
> don't fit into 16 or 32 bits, whichever is the native int size of the  
> compiled executable. 31 should fit in either. So, I don't know how you  
> got here.
>
> [...]
>
> I'd have some ideas. But clearly, that should work if smlrc.exe
> itself is 32-bit.
...


Rod Pemberton

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

#1107

On Wed, 04 Dec 2013 04:31:56 -0500, Rod Pemberton  
<dont_use_email@xnohavenotit.cnm> wrote:
> On Wed, 04 Dec 2013 02:58:30 -0500, Alexei A. Frounze  
> <alexfrunews@gmail.com> wrote:
>> On Tuesday, December 3, 2013 1:26:27 PM UTC-8, Rod Pemberton wrote:
>>> On Tue, 03 Dec 2013 12:23:45 -0500, Rod Pemberton
>>> <dont_use_email@xnohavenotit.cnm> wrote:
>>> > On Sun, 01 Dec 2013 11:15:37 -0500, Alexei A. Frounze

More on that last part:

>>> I'm assuming that's line 383 position 36.  If so,
>>> thats '+':
>>>
>>>    char TokenIdentName[MAX_IDENT_LEN + 1];
>>>
>>> where MAX_IDENT_LEN is #defined as 31.
>>
>> You get "Constant too big for N-bit type" for numeric constants that  
>> don't fit into 16 or 32 bits, whichever is the native int size of the  
>> compiled executable. 31 should fit in either. So, I don't know how you  
>> got here.
>>
>> [...]
>>
>> I'd have some ideas. But clearly, that should work if smlrc.exe
>> itself is 32-bit.

At the "Constant too big for %d-bit type" line in smlrc.c.

SizeOfWord is 4, for 32-bits.
sizeof(n) is 4, where n is an 'unsigned'.
n >> 8 >> 12 >> 12 is 31.
n >> 32 is 0.

Could OW v1.3 be having problems with the multiple shifts?
I'm hoping that's valid C syntax.  I've never seen that.
It's very possible OW v1.3 might not support a bunch of
the C99 or later stuff.  Also, is 'unsigned' the size
you expect?


Rod Pemberton

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

#1108

On Wednesday, December 4, 2013 2:01:02 AM UTC-8, Rod Pemberton wrote:
> On Wed, 04 Dec 2013 04:31:56 -0500, Rod Pemberton  
> <dont_use_email@xnohavenotit.cnm> wrote:
> > On Wed, 04 Dec 2013 02:58:30 -0500, Alexei A. Frounze  
> > <...@gmail.com> wrote:
> >> On Tuesday, December 3, 2013 1:26:27 PM UTC-8, Rod Pemberton wrote:
> >>> On Tue, 03 Dec 2013 12:23:45 -0500, Rod Pemberton
> >>> <dont_use_email@xnohavenotit.cnm> wrote:
> >>> > On Sun, 01 Dec 2013 11:15:37 -0500, Alexei A. Frounze
> 
> More on that last part:
> 
> >>> I'm assuming that's line 383 position 36.  If so,
> >>> thats '+':
> >>>
> >>>    char TokenIdentName[MAX_IDENT_LEN + 1];
> >>>
> >>> where MAX_IDENT_LEN is #defined as 31.
> >>
> >> You get "Constant too big for N-bit type" for numeric constants that  
> >> don't fit into 16 or 32 bits, whichever is the native int size of the  
> >> compiled executable. 31 should fit in either. So, I don't know how you  
> >> got here.
> >>
> >> [...]
> >>
> >> I'd have some ideas. But clearly, that should work if smlrc.exe
> >> itself is 32-bit.
> 
> At the "Constant too big for %d-bit type" line in smlrc.c.
> 
> SizeOfWord is 4, for 32-bits.
> sizeof(n) is 4, where n is an 'unsigned'.
> n >> 8 >> 12 >> 12 is 31.
> n >> 32 is 0.

Precisely. The idea is to make sure that if n (IOW, unsigned) is larger than 32 bits, I can see if it's value doesn't fit into 32 bits.

> Could OW v1.3 be having problems with the multiple shifts?

I don't know for sure, but I bet it very well could (see my bugs filed against OW C/C++ compiler for a few examples of how OW doesn't get some non-rocket-scientific stuff right, e.g. bugs 1106, 1107 and 1148:).

You could run smlrc.exe in wd (first, compile it using /d2 for debug info) and see if the compiler screwed up the generated code somehow. I think it should not be hard since the error occurs very early on.

> I'm hoping that's valid C syntax.  I've never seen that.

Many people have never seen god (perhaps, except in dreams and under influence of substance or brainwashing by parents, community, etc), but claim their existence and ascribe to them lots of stuff too.

Anyway, it's as valid as n + 8 + 12 + 12.

I vaguely remember that Borland/Turbo C/C++ would crash while compiling something equally odd-looking but valid as **********p or &*&*&*&*&*&*p (except the expression was around 50+ operators long). Probably that was just a simple stack overflow in recursion. [smlrc is stack-verflow-prone too, btw, there are no recursion limits, currently]

> It's very possible OW v1.3 might not support a bunch of
> the C99 or later stuff.  Also, is 'unsigned' the size
> you expect?

Yep, 4 8-bit bytes. There's no C99 stuff in the code, except C++ style comments.

You may want to check out djgpp or newer OW.

Alex

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

#1113

On Wed, 04 Dec 2013 05:20:43 -0500, Alexei A. Frounze  
<alexfrunews@gmail.com> wrote:
> On Wednesday, December 4, 2013 2:01:02 AM UTC-8, Rod Pemberton wrote:
>> On Wed, 04 Dec 2013 04:31:56 -0500, Rod Pemberton

More info on this:

>> At the "Constant too big for %d-bit type" line in smlrc.c.
>>
>> SizeOfWord is 4, for 32-bits.
>> sizeof(n) is 4, where n is an 'unsigned'.
>> n >> 8 >> 12 >> 12 is 31.
>> n >> 32 is 0.
>
> Precisely. The idea is to make sure that if n (IOW, unsigned) is larger  
> than 32 bits, I can see if it's value doesn't fit into 32 bits.
>
>> Could OW v1.3 be having problems with the multiple shifts?
>
> I don't know for sure, but I bet it very well could [...]

I did the following:

   changed multiple >> to single in the source
   changed multiple << to single in the source

After that, I get the following error (32-bit):

   Error in "smlrc.c" (374:14)
   Variable(s) take(s) too much space

This seems to be from errorVarSize().  It's the errorVarSize()
call with near "(size != truncUint(size))" in case '(' of
GetDeclSize().  size is 4.  truncUint(size) is 0.  32-bits.
You use ~0u in truncUint().

OpenWatcom v1.3 results of ~0u and with shifts:

wcl/l=dos

~0u         8000ffff
~0u<<15     80000000
~0u<<16         0000
~0u<<8<<7       0002
~0u<<8<<8       6322 or 6333

wcl386/l=dos4g

~0u             ffffffff
~0u<<31         80000000
~0u<<32         ffffffff
~0u<<8<<12<<11  80000000
~0u<<8<<12<<12  00000000


Obviously, some things are not correct or computing as expected.

It appears that Rugxulo has OpenWatcom versions 1.3 and 1.7
on his website:

https://sites.google.com/site/rugxulo/


Rod Pemberton

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

#1116

On Thursday, December 5, 2013 3:33:51 AM UTC-8, Rod Pemberton wrote:
> On Wed, 04 Dec 2013 05:20:43 -0500, Alexei A. Frounze  
> <...@gmail.com> wrote:
> > On Wednesday, December 4, 2013 2:01:02 AM UTC-8, Rod Pemberton wrote:
> >> On Wed, 04 Dec 2013 04:31:56 -0500, Rod Pemberton
> 
> More info on this:
> 
> >> At the "Constant too big for %d-bit type" line in smlrc.c.
> >>
> >> SizeOfWord is 4, for 32-bits.
> >> sizeof(n) is 4, where n is an 'unsigned'.
> >> n >> 8 >> 12 >> 12 is 31.
> >> n >> 32 is 0.
> >
> > Precisely. The idea is to make sure that if n (IOW, unsigned) is larger  
> > than 32 bits, I can see if it's value doesn't fit into 32 bits.
> >
> >> Could OW v1.3 be having problems with the multiple shifts?
> >
> > I don't know for sure, but I bet it very well could [...]
> 
> I did the following:
> 
>    changed multiple >> to single in the source
>    changed multiple << to single in the source
> 
> After that, I get the following error (32-bit):
> 
>    Error in "smlrc.c" (374:14)
> 
>    Variable(s) take(s) too much space
> 
> This seems to be from errorVarSize().  It's the errorVarSize()
> call with near "(size != truncUint(size))" in case '(' of
> GetDeclSize().  size is 4.  truncUint(size) is 0.  32-bits.
> You use ~0u in truncUint().
> 
> OpenWatcom v1.3 results of ~0u and with shifts:
> 
> wcl/l=dos
> 
> ~0u         8000ffff
> ~0u<<15     80000000
> ~0u<<16         0000
> ~0u<<8<<7       0002
> ~0u<<8<<8       6322 or 6333

How come 16-bit ints look like 32-bit? Where's the garbage coming from? I mean "8000" in "8000ffff".

Also, what does "6322 or 6333" mean?

> wcl386/l=dos4g
> 
> ~0u             ffffffff
> ~0u<<31         80000000
> ~0u<<32         ffffffff
> ~0u<<8<<12<<11  80000000
> ~0u<<8<<12<<12  00000000
> 
> Obviously, some things are not correct or computing as expected.

For one thing, you shouldn't be expecting much from shifting a 16-bit int by 16 bit positions or from shifting a 32-bit int by 32 bit positions. Both invoke undefined behavior.

Btw, if there's a bug in OW 1.3's shift handling, you could try using division and multiplication in place of shifts.

> It appears that Rugxulo has OpenWatcom versions 1.3 and 1.7
> on his website:
> https://sites.google.com/site/rugxulo/

What's wrong with the official OW website?

Alex

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

#1119

On Fri, 06 Dec 2013 00:37:26 -0500, Alexei A. Frounze  
<alexfrunews@gmail.com> wrote:
> On Thursday, December 5, 2013 3:33:51 AM UTC-8, Rod Pemberton wrote:
>> On Wed, 04 Dec 2013 05:20:43 -0500, Alexei A. Frounze
>> <...@gmail.com> wrote:
>> > On Wednesday, December 4, 2013 2:01:02 AM UTC-8, Rod Pemberton wrote:
>> >> On Wed, 04 Dec 2013 04:31:56 -0500, Rod Pemberton

>> >> At the "Constant too big for %d-bit type" line in smlrc.c.
>> >>
>> >> SizeOfWord is 4, for 32-bits.
>> >> sizeof(n) is 4, where n is an 'unsigned'.
>> >> n >> 8 >> 12 >> 12 is 31.
>> >> n >> 32 is 0.
>> >
>> > Precisely. The idea is to make sure that if n (IOW, unsigned)
>> > is larger than 32 bits, I can see if it's value doesn't fit
>> > into 32 bits.
>> >
>> >> Could OW v1.3 be having problems with the multiple shifts?
>> >
>> > I don't know for sure, but I bet it very well could [...]
>>
>> I did the following:
>>
>>    changed multiple >> to single in the source
>>    changed multiple << to single in the source
>>
>> After that, I get the following error (32-bit):
>>
>>    Error in "smlrc.c" (374:14)
>>
>>    Variable(s) take(s) too much space
>>
>> This seems to be from errorVarSize().  It's the errorVarSize()
>> call with near "(size != truncUint(size))" in case '(' of
>> GetDeclSize().  size is 4.  truncUint(size) is 0.  32-bits.
>> You use ~0u in truncUint().
>>
>> OpenWatcom v1.3 results of ~0u and with shifts:
>>
>> wcl/l=dos
>>
>> ~0u         8000ffff
>> ~0u<<15     80000000
>> ~0u<<16         0000
>> ~0u<<8<<7       0002
>> ~0u<<8<<8       6322 or 6333
>
> How come 16-bit ints look like 32-bit? Where's the garbage coming from?
> I mean "8000" in "8000ffff".
>

It's coming from the program when it prints the value.

Specifically, it's from a "%04lx" to a printf().  It overflowed.  E.g.,

   printf("%04lx\n",~0u);

Yes, in theory, it should truncate to only four digits for display...

Most likely, the compiler is using a larger intermediate representation,
for some reason, i.e., an "implicit" cast or size conversion.

FYI, a "%08lx" was used for 32-bit values, which displayed 8 digits
for each.

Personally, if I was attempting to do something like this, which I
generally wouldn't because of possible differences in representation,
I would cast to a known size for each compiler, with my preference being
"unsigned long", and logically and & with 0xFFFF or 0xFFFFFFFF, etc.

> Also, what does "6322 or 6333" mean?
>

That depends on the call to truncUint() where I inserted a line to print
all those values.  truncUint() is called multiple times when smrlc compiles
itself.  It seems to print 6322 sometimes and 6333 other times, i.e.,
appears it's being corrupted to me.  The values would tend to imply by
characters overwriting to me, but I have no idea what the values actually
indicate.

>> wcl386/l=dos4g
>>
>> ~0u             ffffffff
>> ~0u<<31         80000000
>> ~0u<<32         ffffffff
>> ~0u<<8<<12<<11  80000000
>> ~0u<<8<<12<<12  00000000
>>
>> Obviously, some things are not correct or computing as expected.
>
> For one thing, you shouldn't be expecting much from shifting a
> 16-bit int by 16 bit positions or from shifting a 32-bit int by
> 32 bit positions. Both invoke undefined behavior.
>

I shouldn't?  You're the one doing so... <<8<<12<<12.  Yes?

I just reduced the shifts to see if multiple shifts were a
parsing issue.

Even if the compiler doesn't optimize them into a single
shift, it's still a total shift of 32 bits.  So, if the
result of that is undefined, then it's undefined either
way, correct? ...

>> It appears that Rugxulo has OpenWatcom versions 1.3 and 1.7
>> on his website:
>> https://sites.google.com/site/rugxulo/
>
> What's wrong with the official OW website?

AFAIK, nothing. they might still have 1.7 around, perhaps 1.3 too.
Of course, they might not, which is what I suspect for 1.3.
Anyway, the point was you could, if you wanted, check each to
find out was is going on without needing me.  It's very possible
1.3 is broken, but then again, maybe not.  If I had 1.7 or 1.9,
I'd test it for you, but I have no plans to install them.
Personally, I decided to move away from using OW, even though
it produces better code, IMO.


Rod Pemberton

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

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.os.msdos.programmer

csiph-web