Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the board
Thread view  Mix view  Order  «  
 
alexfru(R)

USA,
19.06.2016, 00:08

@ Rugxulo

Smaller C compiler

> > > Ah, I had forgotten (since I've never used Plan9) that they were a bit
> > > different. So yeah, perhaps by default they didn't need (or want) a
> > > "full" preprocessor, hence the POSIX environment add-on.
> >
> > I'm not sure what you're talking about.
>
> http://man.cat-v.org/plan_9/1/cpp
>
> "The standard Plan 9 C compilers do not use cpp; they contain their own
> simple but adequate preprocessor, so cpp is usually superfluous."
>
> http://plan9.bell-labs.com/sys/doc/comp.html
>
> "The compilers include an integrated preprocessor that accepts the familiar
> #include, #define for macros both with and without arguments, #undef,
> #line, #ifdef, #ifndef, and #endif. It supports neither #if nor ##,
> although it does honor a few #pragmas. The #if directive was omitted
> because it greatly complicates the preprocessor, is never necessary, and is
> usually abused. Conditional compilation in general makes code hard to
> understand; the Plan 9 source uses it sparingly. Also, because the
> compilers remove dead code, regular if statements with constant conditions
> are more readable equivalents to many #ifs. To compile imported code
> ineluctably fouled by #if there is a separate command, /bin/cpp, that
> implements the complete ANSI C preprocessor specification."

I've read all that before. However, I've missed or forgotten the statement "The compilers include an integrated preprocessor", which may explain certain issues (bugs, etc) in their standalone preprocessor. They simply didn't care much about it and it somehow worked for them in those rare cases they needed it.

As for "perhaps by default they didn't need (or want) a "full" preprocessor, hence the POSIX environment add-on", #if and ## are standard in C and not specific to POSIX. This is why I wasn't sure what you meant.

> > I don't think licenses can travel backwards and then forward again in
> time.
> > The diff between LCC and Plan9 is not GPL'd.
>
> How big a difference (and advantage) is it? Surely you can handle the
> original (worse code but better license).

The diff is not too big or complex, but I'll have to review it because it seems to also fix a few issues. Right now I'm cleaning up and ANSI-C-fying the original code (duplicate work), so it can compile with a standard compiler and minimally function. Then I'll make further fixes and improvements with a few specific for Smaller C.

Alex

alexfru(R)

USA,
19.06.2016, 00:22

@ Rugxulo

Smaller C compiler

> > > Sadly, some people have no imagination, certainly regarding DOS.
> >
> > My compiler targets Windows, Linux and RetroBSD as well, so, it's either
> > the compiler or all four OSes. :)
>
> You've done a very impressive job, so if your compiler isn't being
> significantly tested by outside developers, then I blame them, not you.
> That's what I meant. Developers can be narrow-minded, stuck in their ways
> ("all the world's a VAX").

Thanks. :)

> Plus I think a lot of projects are too non-portable (or at least haven't
> well isolated the system-specific stuff). That probably doesn't help.

The standard C is missing a few important things, which make it difficult to make a fully portable compiler. E.g. there's only system() for you to execute some other program. But the standard does not even require system() to return back to the caller and it doesn't tell how to interpret the returned value. And there's nothing in the standard about special symbols and various quotation and escaping mechanisms of the "command processor" (AKA shell). However, in DOS, Windows and Linux, system() normally returns and (with the exception of DOS's COMMAND.COM) it returns 0 on success and non-zero on failure. So, if you're conservative and cautious, you can use system() on selected platforms, perhaps only with minor platform specialization and trickery.

> > > Isn't ancient GCC 2.7's CPP fairly small? I imagine that would be
> > > (relatively) easy to port.
> >
> > I haven't seen it, but I have doubts.
>
> It's fairly small, but it too is probably very POSIX heavy (or maybe relies
> on other weird stuff, alloca??). Dunno, maybe a bad suggestion, I too
> haven't looked closely.

If I'm unhappy with Plan9's, I may take a look.

> > I didn't know about that. I have plan9.iso.bz2 downloaded in January
> 2015
> > from Lucent.
>
> http://akaros.cs.berkeley.edu/files/Plan9License says this:
>
> "The University of California, Berkeley, has been authorised by
> Alcatel-Lucent to release all Plan 9 software previously governed by
> the Lucent Public License, Version 1.02 under the GNU General
> Public License, Version 2."
>
> So if you're worried about licensing, use that version. It can't be much
> worse than LCC's fork, can it?

Not significantly.

Alex

Rugxulo(R)

Homepage

Usono,
19.06.2016, 01:56

@ alexfru

Smaller C compiler

> I've read all that before. However, I've missed or forgotten the statement
> "The compilers include an integrated preprocessor", which may explain
> certain issues (bugs, etc) in their standalone preprocessor. They simply
> didn't care much about it and it somehow worked for them in those rare
> cases they needed it.
>
> As for "perhaps by default they didn't need (or want) a "full"
> preprocessor, hence the POSIX environment add-on", #if and ## are standard
> in C and not specific to POSIX. This is why I wasn't sure what you meant.

Even though I've never used it, I was referring to this:

APE ? The ANSI/POSIX Environment

Rugxulo(R)

Homepage

Usono,
19.06.2016, 02:22

@ alexfru

Smaller C compiler

> Btw, did I tell you that Smaller C has basic floating point support now?

I did notice already on Github, but none of my wimpy code needs it.

> (I shouldn't probably mention on this forum that it can also make Windows
> GUI apps (there's a small clock demo for SDL2.dll))

I saw that too but never tried it. However, since you mentioned it, just FYI ....

At one time the remake of Atomiks (by Mateusz Viste), at least the Win32 .EXE using SDL 1.2, ran under HX/DOS. So ....

alexfru(R)

USA,
20.06.2016, 07:51

@ alexfru

Smaller C compiler

> > > > Isn't ancient GCC 2.7's CPP fairly small? I imagine that would be
> > > > (relatively) easy to port.
> > >
> > > I haven't seen it, but I have doubts.
> >
> > It's fairly small, but it too is probably very POSIX heavy (or maybe
> relies
> > on other weird stuff, alloca??). Dunno, maybe a bad suggestion, I too
> > haven't looked closely.
>
> If I'm unhappy with Plan9's, I may take a look.

So, I've cleaned up and ANSI-C-fied the original Plan9's preprocessor and decided to compare it with the LCC version. It's funny, but there are bugs in both as can be seen when feeding them examples from the C standard. LCC aims at fixing some of them, but has a mixed success. It fixes a couple, fails to fix another and on some input just hangs. I might spend some cycles to investigate and fix some of these, but it's a bit of a bummer. I had higher expectations for this preprocessor.

There's another one (ucpp) and it seems to pass those tests and it's BSD-licensed, but it's larger and needs to be split into more .c files for compilation with Smaller C (alternatively, smlrc may be recompiled to accommodate for larger .c files).

We'll see...

Alex

Oso2k(R)

04.07.2016, 07:22

@ Rugxulo

Smaller C compiler

If you're not a fan of that other ucpp, you can try my copy which is minimally changed from Thomas P's version (make file only, a couple bug fixes, easy to embed). Btw, I'm the upstream the other ucpp links to on code.google.com.

https://github.com/lpsantil/ucpp

alexfru(R)

USA,
10.07.2016, 08:19

@ Oso2k

Smaller C compiler

> If you're not a fan of that other ucpp, you can try my copy which is
> minimally changed from Thomas P's version (make file only, a couple bug
> fixes, easy to embed). Btw, I'm the upstream the other ucpp links to on
> code.google.com.
>
> https://github.com/lpsantil/ucpp

I've actually almost finished integrating it with Smaller C. You can get the work-in-progress from a temporary branch, ucpp (will disappear once merged into master). It seems to be working.

Rugxulo(R)

Homepage

Usono,
30.07.2016, 07:20

@ alexfru

Smaller C compiler

> I've actually almost finished integrating it with Smaller C.
> It seems to be working.

Nice work! Good job! :ok:

alexfru(R)

USA,
30.07.2016, 07:54

@ Rugxulo

Smaller C compiler

> > I've actually almost finished integrating it with Smaller C.
> > It seems to be working.
>
> Nice work! Good job! :ok:

Thanks! :)

Rugxulo(R)

Homepage

Usono,
09.08.2016, 18:40
(edited by Rugxulo, 09.08.2016, 20:38)

@ alexfru

Smaller C compiler

BTW, I've never looked closely, but I'm not sure your tmpfile handling works correctly in FreeDOS. It doesn't seem to find %TEMP% or %TMP%, instead preferring current dir (e.g. "@.\TMP00002.$$$").

Even worse, although I admit this is an extremely rare scenario, when I boot up my old P4 (using PLoP Boot Manager), there is no real hard disk, thus "C:\" is (read-only) USB, which of course confuses smlrcc (despite %TEMP%, %TMP%, %TMPDIR% pointing to RAM disk!!), causing a critical error.

(Honestly, I don't know, this could be some rare FreeDOS bug/compatibility quirk. I vaguely remember some weirdness in findfirst re: dirs.)

Maybe "-tmpdir" option to override auto-detection would be easier?

EDIT: "g:" and "g:\" both work okay, but (default) "g:\temp" doesn't (nor do several other variations), if that helps narrow things down.

alexfru(R)

USA,
10.08.2016, 09:38

@ Rugxulo

Smaller C compiler

> BTW, I've never looked closely, but I'm not sure your tmpfile handling
> works correctly in FreeDOS. It doesn't seem to find %TEMP% or %TMP%,
> instead preferring current dir (e.g. "@.\TMP00002.$$$").
>
> Even worse, although I admit this is an extremely rare scenario, when I
> boot up my old P4 (using PLoP Boot Manager), there is no real hard disk,
> thus "C:\" is (read-only) USB, which of course confuses smlrcc (despite
> %TEMP%, %TMP%, %TMPDIR% pointing to RAM disk!!), causing a critical error.
>
> (Honestly, I don't know, this could be some rare FreeDOS bug/compatibility
> quirk. I vaguely remember some weirdness in findfirst re: dirs.)

I'll take a look later this week.

> Maybe "-tmpdir" option to override auto-detection would be easier?

I don't think this should be needed once the issue is understood and resolved.

> EDIT: "g:" and "g:\" both work okay, but (default) "g:\temp" doesn't (nor
> do several other variations), if that helps narrow things down.

What do you mean by that? Are you saying that setting TEMP=g:\ or TEMP=g: works, while TEMP=g:\temp doesn't?

alexfru(R)

USA,
10.08.2016, 13:40

@ Rugxulo

Smaller C compiler

> BTW, I've never looked closely, but I'm not sure your tmpfile handling
> works correctly in FreeDOS. It doesn't seem to find %TEMP% or %TMP%,

It turns out I'd messed up slashes when passing paths to function 0x4300 to see if %TEMP% exists as a directory. C:\ and C:\FOO are OK, but C: and C:\FOO\ are not. Since I always had writable C: with enough space and on Windows smlrcc does not invoke tmpfile(), I never saw the problem. It's also possible that Windows and/or DOSBox was too forgiving when I looked at this some time ago and saw no obvious problem.

Try the updated binaries and libraries.

Rugxulo(R)

Homepage

Usono,
10.08.2016, 16:40

@ alexfru

Smaller C compiler

> Try the updated binaries and libraries.

Some quick testing under VM (FreeDOS) shows that it works okay now.

Rugxulo(R)

Homepage

Usono,
19.08.2016, 03:10

@ alexfru

Smaller C compiler

(This is almost too trivial or redundant to even mention, but alas ....)

Your main Github page points to this (now broken) link:

CWSDPMI: http://homer.rice.edu/~sandmann/cwsdpmi/

But you can still find it on DJGPP mirrors under /current/v2misc/ .

It's also recently been mirrored on iBiblio for FreeDOS.

Another related issue is your wiki section regarding this:

> -maxheap <number> Specifies the maximum heap size (in bytes)
> for DPMI programs. To be used with option -dosp. If the option isn't
> given, the linker assumes 16777216 (16MB). The number can be decimal,
> hex or octal. The program may receive a heap whose size is smaller
> than this number (e.g. if there isn't this much free DPMI memory;
> Windows XP can provide up to ~1GB of DPMI memory while Windows Vista/7
> is known to limit DPMI memory to 16MB).

I haven't used 32-bit Windows in several years, since my Vista laptop died, but AFAIK the limit was (default) 32 MB, only adjustable (with SP1) with a registry hack. "Add registry entry 'DpmiLimit' with large enough
value to Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WOW ".

alexfru(R)

USA,
19.08.2016, 08:55

@ Rugxulo

Smaller C compiler

> (This is almost too trivial or redundant to even mention, but alas ....)
>
> Your main Github page points to this (now broken) link:
>
> CWSDPMI: http://homer.rice.edu/~sandmann/cwsdpmi/

The entire homer isn't accessible. Odd.

> But you can still find it on DJGPP mirrors under
> /current/v2misc/
> .
>
> It's also recently been mirrored on
> iBiblio
> for FreeDOS.

Yeah, I can link to e.g. DJGPP's servers.

> Another related issue is your wiki section regarding this:
>
> > -maxheap <number> Specifies the maximum heap size (in bytes)
> > for DPMI programs. To be used with option -dosp. If the option isn't
> > given, the linker assumes 16777216 (16MB). The number can be decimal,
> > hex or octal. The program may receive a heap whose size is smaller
> > than this number (e.g. if there isn't this much free DPMI memory;
> > Windows XP can provide up to ~1GB of DPMI memory while Windows Vista/7
> > is known to limit DPMI memory to 16MB).
>
> I haven't used 32-bit Windows in several years, since my Vista laptop died,
> but AFAIK the limit was (default) 32 MB, only adjustable (with SP1) with a
> registry hack. "Add registry entry 'DpmiLimit' with large enough
> value to Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WOW
> ".

It's probably a typo (I want to check with my 32-bit Windows 7). I was probably thinking of DOSBox at the time or about the -maxheap default.

alexfru(R)

USA,
28.08.2016, 08:46

@ alexfru

Smaller C compiler

> > (This is almost too trivial or redundant to even mention, but alas ....)
> >
> > Your main Github page points to this (now broken) link:
> >
> > CWSDPMI: http://homer.rice.edu/~sandmann/cwsdpmi/
>
> The entire homer isn't accessible. Odd.
>
> > But you can still find it on DJGPP mirrors under
> >
> /current/v2misc/
> > .
> >
> > It's also recently been mirrored on
> >
> iBiblio
> > for FreeDOS.
>
> Yeah, I can link to e.g. DJGPP's servers.

I wrote an e-mail to the author to see if he's going to upload it anywhere else. Mentioned github.

> > Another related issue is your wiki section regarding this:
> >
> > > -maxheap <number> Specifies the maximum heap size (in bytes)
> > > for DPMI programs. To be used with option -dosp. If the option isn't
> > > given, the linker assumes 16777216 (16MB). The number can be decimal,
> > > hex or octal. The program may receive a heap whose size is smaller
> > > than this number (e.g. if there isn't this much free DPMI memory;
> > > Windows XP can provide up to ~1GB of DPMI memory while Windows Vista/7
> > > is known to limit DPMI memory to 16MB).
> >
> > I haven't used 32-bit Windows in several years, since my Vista laptop
> died,
> > but AFAIK the limit was (default) 32 MB, only adjustable (with SP1) with
> a
> > registry hack. "Add registry entry 'DpmiLimit' with large enough
> > value to
> Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WOW
> > ".
>
> It's probably a typo (I want to check with my 32-bit Windows 7). I was
> probably thinking of DOSBox at the time or about the -maxheap default.

Just checked, indeed 32MB is the default DPMI max under Windows 7. The number is updated, thanks!

alexfru(R)

USA,
14.12.2016, 08:50

@ alexfru

Smaller C compiler

> > >
> > > Your main Github page points to this (now broken) link:
> > >
> > > CWSDPMI: http://homer.rice.edu/~sandmann/cwsdpmi/
> >
> > The entire homer isn't accessible. Odd.
> >
> > > But you can still find it on DJGPP mirrors under
> > >
> >
> /current/v2misc/
> > > .
> > >
> > > It's also recently been mirrored on
> > >
> >
> iBiblio
> > > for FreeDOS.
> >
> > Yeah, I can link to e.g. DJGPP's servers.
>
> I wrote an e-mail to the author to see if he's going to upload it anywhere
> else. Mentioned github.

Just got an e-mail from Charles:

----8<----
http://sandmann.dotster.com/index1.html
http://sandmann.dotster.com/cwsdpmi/

(I am working on a nicer DNS / redirect)

I have just been exceptionally busy. This will also restore the win2k pages and some other things I have provided in the past. Perhaps we should consider what is really important and also mirror on DJ?s server.

BTW, my EarthLink email addresses are probably dying end of this month, so I need to set up a replacement on one of my domains (but I need to change about 200 email pointers first).
----8<----

So, things may change again.

Rugxulo(R)

Homepage

Usono,
14.05.2017, 22:29

@ alexfru

Smaller C compiler

> news://comp.os.msdos.programmer on Wed 07 Sep 2016
>
> I don't remember if my compiler's output assembles with
> jump optimization disabled. It might not. I know that
> old versions of NASM used not to assemble it because by
> default NASM would not extend conditional jumps beyond
> the short -128/+127 range.

Yes, if "cpu 8086" is used, even with -O0, it will still workaround this architectural limit with two jumps behind the scenes.

But does your compiler need 8086? I thought it was 386+ only? You don't have such range limits in 386 jumps.

So I have no idea if you can speed up your tests by "set NASMENV=-O0" or not. Try it and see. At least one of my simple programs still compiled and ran okay with -O0.

alexfru(R)

USA,
17.05.2017, 08:33

@ Rugxulo

Smaller C compiler

> > news://comp.os.msdos.programmer on Wed 07 Sep 2016
> >
> > I don't remember if my compiler's output assembles with
> > jump optimization disabled. It might not. I know that
> > old versions of NASM used not to assemble it because by
> > default NASM would not extend conditional jumps beyond
> > the short -128/+127 range.
>
> Yes, if "cpu 8086" is used, even with -O0, it will still workaround this
> architectural limit with two jumps behind the scenes.
>
> But does your compiler need 8086? I thought it was 386+ only? You don't
> have such range limits in 386 jumps.

It is 386+ only. But *old* NASM wouldn't assemble the compiler output.

> So I have no idea if you can speed up your tests by "set NASMENV=-O0" or
> not. Try it and see. At least one of my simple programs still compiled and
> ran okay with -O0.

It helps a tiny bit.

Compiling main compiler file for Windows under Windows:

Using NASM (the default; no NASMENV):
smlrcc -c smlrc.c
8 seconds

Using NASM (the default; NASMENV=-O0):
smlrcc -c smlrc.c
5 seconds

Using YASM:
smlrcc -c smlrc.c -asm yasm
1 second

Using FASM + n2f:
smlrcc -c smlrc.c -asm n2f
1 second

The difference between assemblers is huge as you can see.

Rugxulo(R)

Homepage

Usono,
18.06.2017, 07:47

@ alexfru

Smaller C compiler

> > So I have no idea if you can speed up your tests by "set NASMENV=-O0"
>
> It helps a tiny bit.

So what about using "-a"? I haven't tested it, but they claim its
faster:

http://www.nasm.us/xdoc/2.13.01/html/nasmdoc2.html#section-2.1.21

> If NASM is being used as the back end to a compiler, it might
> be desirable to suppress preprocessing completely and assume
> the compiler has already done it, to save time and increase
> compilation speeds. The -a option, requiring no argument,
> instructs NASM to replace its powerful preprocessor with a
> stub preprocessor which does nothing.

Rugxulo(R)

Homepage

Usono,
18.06.2017, 20:31

@ Rugxulo

Smaller C compiler

> So what about using "-a"? I haven't tested it, but they claim its
> faster:

No, it won't work ... by default, without minor fixes:

http://www.nasm.us/xdoc/2.13.01/html/nasmdoc6.html

> Primitive directives are enclosed in square brackets;
> user-level directives are not.

So "bits", "section", "global", "extern", etc. need to be surrounded by square brackets, e.g. "[bits 16]" in order for "-a" to not error out.

Then it seems to assemble identically to before.

Back to the board
Thread view  Mix view  Order  «  
 
15115 Postings in 1359 Threads, 249 registered users, 15 users online (0 registered, 15 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum