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

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

Re: C2 Aims to Modernize the C Language

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

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: C2 Aims to Modernize the C Language David Kleinecke <dkleinecke@gmail.com> - 2018-02-10 12:41 -0800
    Re: C2 Aims to Modernize the C Language Chad <cdalten@gmail.com> - 2018-02-10 13:38 -0800
    Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-11 00:32 +0100
      Re: C2 Aims to Modernize the C Language Thiago Adams <thiago.adams@gmail.com> - 2018-02-10 17:23 -0800
        Re: C2 Aims to Modernize the C Language Anton Shepelev <anton.txt@gmail.com> - 2018-02-11 13:53 +0300
          Re: C2 Aims to Modernize the C Language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-11 13:26 +0000
          Re: C2 Aims to Modernize the C Language Thiago Adams <thiago.adams@gmail.com> - 2018-02-11 13:04 -0800
      Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-11 01:34 +0000
        Re: C2 Aims to Modernize the C Language Thiago Adams <thiago.adams@gmail.com> - 2018-02-10 17:42 -0800
          Re: C2 Aims to Modernize the C Language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-02-10 17:50 -0800
            Re: C2 Aims to Modernize the C Language fir <profesor.fir@gmail.com> - 2018-02-14 11:54 -0800
              Re: C2 Aims to Modernize the C Language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-02-14 12:14 -0800
        Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-11 04:48 +0100
          Re: C2 Aims to Modernize the C Language Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-10 22:35 -0700
            Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-11 13:25 +0100
          Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-11 11:18 +0000
            Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-11 21:57 +0000
              Re: C2 Aims to Modernize the C Language Ian Collins <ian-news@hotmail.com> - 2018-02-12 14:10 +1300
                Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 11:11 +0000
                  Re: C2 Aims to Modernize the C Language Reinhardt Behm <rbehm@hushmail.com> - 2018-02-12 20:33 +0800
                    Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 13:43 +0000
                      Re: C2 Aims to Modernize the C Language Thiago Adams <thiago.adams@gmail.com> - 2018-02-12 06:05 -0800
                  Re: C2 Aims to Modernize the C Language Ian Collins <ian-news@hotmail.com> - 2018-02-13 07:13 +1300
                    Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-13 01:17 +0000
                      Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-13 09:55 +0100
                        Re: C2 Aims to Modernize the C Language BGB <cr88192@hotmail.com> - 2018-02-13 12:28 -0600
                          Re: C2 Aims to Modernize the C Language Ian Collins <ian-news@hotmail.com> - 2018-02-14 11:36 +1300
                            Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-14 00:59 +0000
                              Re: C2 Aims to Modernize the C Language Ian Collins <ian-news@hotmail.com> - 2018-02-14 15:19 +1300
                                Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-14 14:07 +0000
                                  Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-03-06 15:46 +0000
                            Re: C2 Aims to Modernize the C Language BGB <cr88192@hotmail.com> - 2018-02-13 20:31 -0600
                              Re: C2 Aims to Modernize the C Language Ian Collins <ian-news@hotmail.com> - 2018-02-14 15:42 +1300
                                Re: C2 Aims to Modernize the C Language BGB <cr88192@hotmail.com> - 2018-02-14 01:13 -0600
                                Re: C2 Aims to Modernize the C Language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-21 15:13 +0000
                                  Re: C2 Aims to Modernize the C Language supercat@casperkitty.com - 2018-02-21 08:43 -0800
                                    Re: C2 Aims to Modernize the C Language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-21 19:21 +0000
                                  Re: C2 Aims to Modernize the C Language Robert Wessel <robertwessel2@yahoo.com> - 2018-02-21 12:25 -0600
                                    Re: C2 Aims to Modernize the C Language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-21 19:28 +0000
                                      Re: C2 Aims to Modernize the C Language Robert Wessel <robertwessel2@yahoo.com> - 2018-02-21 18:29 -0600
                                  Re: C2 Aims to Modernize the C Language Ian Collins <ian-news@hotmail.com> - 2018-02-22 08:33 +1300
                              Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-14 14:48 +0000
                                Re: C2 Aims to Modernize the C Language BGB <cr88192@hotmail.com> - 2018-02-14 11:54 -0600
                        Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-13 20:41 +0000
            Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-12 00:00 +0100
              Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 00:59 +0000
                Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-12 12:29 +0100
                  Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 12:18 +0000
                    Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-12 15:27 +0100
                      Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 15:19 +0000
                        Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-12 16:49 +0100
                          Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 17:16 +0000
                            Re: C2 Aims to Modernize the C Language Ian Collins <ian-news@hotmail.com> - 2018-02-13 07:30 +1300
                            Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-12 22:37 +0100
                              Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 22:15 +0000
                                Re: C2 Aims to Modernize the C Language Ian Collins <ian-news@hotmail.com> - 2018-02-13 17:05 +1300
                                  Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-13 11:11 +0000
                                Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-13 10:32 +0100
                                  Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-13 11:10 +0000
                                    Re: C2 Aims to Modernize the C Language gordonb.5itdn@burditt.org (Gordon Burditt) - 2018-02-14 12:57 -0600
                                      Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-14 20:29 +0000
                                        Re: C2 Aims to Modernize the C Language gordonb.nrdl0@burditt.org (Gordon Burditt) - 2018-02-14 19:22 -0600
                                          Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-15 14:59 +0000
                                  Re: C2 Aims to Modernize the C Language already5chosen@yahoo.com - 2018-02-13 04:00 -0800
                                    Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-13 14:46 +0100
                                      Re: C2 Aims to Modernize the C Language already5chosen@yahoo.com - 2018-02-13 08:49 -0800
                                        Re: C2 Aims to Modernize the C Language Thiago Adams <thiago.adams@gmail.com> - 2018-02-13 09:52 -0800
                                  Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-13 13:47 +0100
                                    Re: C2 Aims to Modernize the C Language already5chosen@yahoo.com - 2018-02-13 05:11 -0800
                                      Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-13 14:49 +0100
                                        Re: C2 Aims to Modernize the C Language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-02-13 21:52 +0800
                                        Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-13 14:45 +0000
                                        Re: C2 Aims to Modernize the C Language Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-13 07:45 -0800
                                    Re: C2 Aims to Modernize the C Language Chad <cdalten@gmail.com> - 2018-02-13 05:35 -0800
                                  Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-13 13:21 +0000
                                    Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-13 13:24 +0000
                    Re: C2 Aims to Modernize the C Language Egor <egor@ruby.local> - 2018-02-13 13:14 +0200
                      Re: C2 Aims to Modernize the C Language already5chosen@yahoo.com - 2018-02-13 04:38 -0800
                        Re: C2 Aims to Modernize the C Language Egor <egor@ruby.local> - 2018-02-14 13:25 +0200
                      Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-13 13:39 +0000
                        Re: C2 Aims to Modernize the C Language Egor <egor@ruby.local> - 2018-02-14 13:42 +0200
      Re: C2 Aims to Modernize the C Language supercat@casperkitty.com - 2018-02-15 13:17 -0800
    Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-11 04:41 +0100
    Re: C2 Aims to Modernize the C Language Manfred <noname@invalid.add> - 2018-02-12 17:25 +0100
      Re: C2 Aims to Modernize the C Language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-12 17:28 +0000
        Re: C2 Aims to Modernize the C Language Manfred <noname@invalid.add> - 2018-02-12 21:01 +0100
      Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 17:51 +0000
        Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-12 19:28 +0100
          Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 20:02 +0000
            Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-12 23:32 +0100
              Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-13 10:42 +0100
                Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-13 13:26 +0100
                  Re: C2 Aims to Modernize the C Language Richard Damon <Richard@Damon-Family.org> - 2018-02-13 08:06 -0500
                    Re: C2 Aims to Modernize the C Language Manfred <noname@invalid.add> - 2018-02-13 15:16 +0100
                  Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-13 14:53 +0100
                    Re: C2 Aims to Modernize the C Language BGB <cr88192@hotmail.com> - 2018-02-13 15:22 -0600
          Re: C2 Aims to Modernize the C Language Keith Thompson <kst-u@mib.org> - 2018-02-12 12:26 -0800
            Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-12 23:45 +0100
            Re: C2 Aims to Modernize the C Language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-02-12 15:52 -0800
              Re: C2 Aims to Modernize the C Language Chad <cdalten@gmail.com> - 2018-02-12 17:13 -0800
        Re: C2 Aims to Modernize the C Language Manfred <noname@invalid.add> - 2018-02-12 21:15 +0100
          Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 21:42 +0000
            Re: C2 Aims to Modernize the C Language Manfred <noname@invalid.add> - 2018-02-12 23:21 +0100

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

#126948

On 02/22/2018 04:13 AM, Jorgen Grahn wrote:
> On Wed, 2018-02-14, Ian Collins wrote:
>> On 02/14/2018 03:31 PM, BGB wrote:
> ....
>>> when I rebuilt LLVM before, generally I was seeing a number of instances
>>> of "ld" in task manager, each typically using between around 8 and 12 GB
>>> (hence the 112GB pagefile).
>>>
>>> this property appears to be mostly unique to LLVM.
>>
>> Not uncommon with large statically linked C++ application unfortunately.
>> My build node ended up using over 90GB during the link and got a little
>> upset...  For our own code we have modified the generated ninja build
>> files to restrict the number of concurrent links.
> 
> Is this with link-time optimization?  As far as I can tell, tradi-
> tional static linking shouldn't have to keep more in memory than the
> symbols seen so far.

The linker does a lot more work with C++ than it does with C, especially 
if the code makes heavy use of templates.  It also has to ingest all of 
the object files, which can be well bloated with debug symbols.

> (I also believe linking N object files is less efficient than linking
> against a static library containing N object files, but I don't have
> any evidence for that.)

Given static libraries are simple archives of object files, I'd be 
surprised.  The linker could perform duplicate code elimination for 
static libraries, but I don't know of any that do (or whether it would 
be allowed!).

-- 
Ian.

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

#126691

On 14/02/2018 02:31, BGB wrote:

> in contrast: Quake 1 (built with GCC) is around 35 seconds.
> 
> Quake 1 is around 8 seconds if built with MSVC, and around 6 seconds 
> with my compiler (... somehow ...).

I had a look at Quake. It was a more sprawling application than I'd 
expected, so I looked only at compiling the .c files in the main 
WinQuake directory (from https://github.com/id-Software/Quake).

I can't do make files or project or anything like that, so I selected 79 
or the 127 .c files that compiled without errors on gcc.

Of those, I chose 69 that worked with my own C compiler. (The other 10 
had missing headers, missing Win32 functions, had errors ignored by gcc, 
or there were problems in my compiler. But other compilers had problems 
too.)

Anyway, compiling all 69 files (one at a time using a .bat file and also 
all at once using an @file) took:

       .bat   @file

MSVC  12.6   5.6 seconds   (all unoptimised)
gcc    9.9   8.8 seconds
mcc    3.3   --

Mcc is my compiler, and the actual timing is 2.4 + 0.9 seconds (compile 
then assemble as it's currently split into two parts).

It should be considerably faster, but having to invoke those programs 
138 times seems to have taken its toll. If I modify Mcc so that it 
doesn't do the compilation, then it still takes 2.15 seconds, instead of 
2.40.

So I need to modify Mcc to compile multiple modules. (I hadn't bothered 
before because I wanted to do a whole-project compiler, but C doesn't 
have the module system needed to do that effectively, so it didn't seem 
worthwhile.)

-----------------

(If I 'transpile' my Mcc project into a single C source file (17Kloc), 
and compile it with itself, then total time taken is 0.08 seconds 
(measured by a program running system(<cmdline>) and clock() calls 
before and after). Note that running Hello World took 0.03 seconds 
measured the same way.

But the true compile time is probably less than 0.03 seconds, as there 
are overheads in starting and terminating processes that are not part of 
the compile process. It's hard to measure actual compilation time at 
these speeds.

You need true compilation time because the compiler might be run as an 
in-memory library function with a string as input and a string as 
output; no process starting or file operations would be involved.


-- 
bartc

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

#126697

On 2/14/2018 8:48 AM, bartc wrote:
> On 14/02/2018 02:31, BGB wrote:
> 
>> in contrast: Quake 1 (built with GCC) is around 35 seconds.
>>
>> Quake 1 is around 8 seconds if built with MSVC, and around 6 seconds 
>> with my compiler (... somehow ...).
> 
> I had a look at Quake. It was a more sprawling application than I'd 
> expected, so I looked only at compiling the .c files in the main 
> WinQuake directory (from https://github.com/id-Software/Quake).
> 
> I can't do make files or project or anything like that, so I selected 79 
> or the 127 .c files that compiled without errors on gcc.
> 

it is worth noting that Quake has a lot of target-specific files.

in my case, I had made a custom target to allow it to run in a "bare 
metal" configuration, linked with a C library containing some of the 
hardware glue (and filesystem stuff, ...).

but, a nifty thing about Quake is that it seems to be reasonably good at 
pointing out if compiler bugs exist (reasonably good coverage of various 
parts of the language, ...), and generally provides fairly obvious 
feedback if something isn't working quite right.

it doesn't detect everything though, so my version ended up with some 
amount of additional sanity-check logic glued on:
   if(something_being_tested!=value_I_expect)
     __debugbreak();

occasionally switching it up to try to avoid too much "complacency", and 
some logic which tries to effectively circumvent some optimizations my 
compiler uses (trying to prevent things like constant propagation from 
optimizing away the checks, ...).

with its software renderer, it also works decently as a benchmark of sorts.


one notable omission though, is that it doesn't really test features 
beyond C90 (ex: no "long long" or other C99 features), so need 
additional code to test that a lot of this stuff works (mine only 
supports parts of C99 though, so is sort of in a similar camp to MSVC here).


> Of those, I chose 69 that worked with my own C compiler. (The other 10 
> had missing headers, missing Win32 functions, had errors ignored by gcc, 
> or there were problems in my compiler. But other compilers had problems 
> too.)
> 
> Anyway, compiling all 69 files (one at a time using a .bat file and also 
> all at once using an @file) took:
> 
>        .bat   @file
> 
> MSVC  12.6   5.6 seconds   (all unoptimised)
> gcc    9.9   8.8 seconds
> mcc    3.3   --
> 
> Mcc is my compiler, and the actual timing is 2.4 + 0.9 seconds (compile 
> then assemble as it's currently split into two parts).
> 
> It should be considerably faster, but having to invoke those programs 
> 138 times seems to have taken its toll. If I modify Mcc so that it 
> doesn't do the compilation, then it still takes 2.15 seconds, instead of 
> 2.40.
> 
> So I need to modify Mcc to compile multiple modules. (I hadn't bothered 
> before because I wanted to do a whole-project compiler, but C doesn't 
> have the module system needed to do that effectively, so it didn't seem 
> worthwhile.)
> 

mine ("BGBCC") is essentially a "whole program" compiler internally.

generally, I was building things by giving the compiler all the source 
files all at once.


BGBCC should be able to be used in "file at a time", but its 
intermediate output would be "RIL3" bytecode files, rather than COFF or 
ELF objects. the RIL3 is not present in the output program, but is 
merely used as an IR.

GCC is actually able to do something "similar", just producing ".o" 
files which contain a big blob of its GIMPLE IR.

though, RIL3 and GIMPLE are otherwise quite different.


> -----------------
> 
> (If I 'transpile' my Mcc project into a single C source file (17Kloc), 
> and compile it with itself, then total time taken is 0.08 seconds 
> (measured by a program running system(<cmdline>) and clock() calls 
> before and after). Note that running Hello World took 0.03 seconds 
> measured the same way.
> 
> But the true compile time is probably less than 0.03 seconds, as there 
> are overheads in starting and terminating processes that are not part of 
> the compile process. It's hard to measure actual compilation time at 
> these speeds.
> 
> You need true compilation time because the compiler might be run as an 
> in-memory library function with a string as input and a string as 
> output; no process starting or file operations would be involved.
> 


mine was originally developed (around a decade ago) with the original 
intention of being used for using C as a scripting language. at the 
time, it "sucked really hard", and my original backend imploded due to 
it effectively being beyond my debugging abilities at the time.

then it ended up being used for a few years mostly as a 
header-processing tool.

a few years ago, it was revived again, but used to target a bytecode I 
had called FRBC and a VM which I had called FRVM, which had its bytecode 
essentially in a 3-address register-based form. it was originally 
partially inspired by Dalvik, but I soon found that the VM had some 
serious design flaws. its "high point" was me sort of being able to 
target Quake to it, and ending up used as special purpose VM within some 
of my robot/electronics projects.

some issues with this project prompted me to create a new VM and 
language I had called BS2, originally intended as a lighter-weight 
alternative (for real-time robotics stuff).

when I subsequently implemented the BS2 VM, I reverted back to a 
stack-machine model, but had retain some aspects of the prior VM design. 
a big realization was that, while 3AC is better for performance, it is 
essentially trivial to convert well-formed RPN to 3AC at load-time.


more recently, I did a fork of the prior C compiler, just reworking it 
to produce SuperH machine-code rather than FRBC (I ended up initially 
focusing mostly on SH4, as this was basically the "minimum spec" needed 
to run Quake).

I then expanded the SH4 ISA into a form I have called "BJX1", which in 
some ways partially recreates some aspects of the FRBC design.

on notable difference though is that BJX1 is more viable as a machine 
ISA, and I had since been working on trying to do an implementation on 
an FPGA (seeing if I can build something sufficient to run Quake on an 
Spartan 7 / XC7S50), and clocking the CPU core at 100 MHz (this part is 
being written in Verilog).

however, the XC7S50 isn't really "beefy" enough to handle doing a 
superscalar processor, and the ~ 70..100 MIPs I can get at 100MHz isn't 
really sufficient for good framerates, so I have also been investigating 
a variant of the ISA which is based around hybridizing it with VLIW 
(sort of vaguely similar to the Itanium/IA64 ISA), which, at least on 
the hardware front, can get higher throughput with a more modest 
increase in cost (ex: can still fit in the FPGA).

if I can get ~ 200-300 MIPs, I can also get good framerates; ex: staying 
more reliably in the 30-60 fps range.

however, on the compiler side of things, VLIW is a bit more of a pain 
than a more conventional RISC or CISC style ISA, and sort of hackishly 
gluing a 16/32 RISC and VLIW style ISA together looks a bit like a nasty 
mess (this is along with making design tweaks to shave off costs in 
other areas).

a newer form of this has basically turned into something mutilated 
almost beyond recognition if compared with the original SH4 ISA design 
(like, replacing the boat piece by piece, just with ISA design...).

note that for these projects I am also relying heavily on emulation and 
simulation, and not a whole lot has ended up hitting "real hardware" as 
of yet (synthesis is being used, but mostly to validate resource cost 
and whether everything passes timing constraints and similar).

but, I am not sure if this whole project has much point, and it has 
ended up thus far effectively ended up eating up a pretty absurd amount 
of my time... (like I seemingly just keep going further down this rabbit 
hole...).


or such...

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

#126678

On 13/02/2018 08:55, David Brown wrote:
> On 13/02/18 02:17, bartc wrote:
>> On 12/02/2018 18:13, Ian Collins wrote:
>>> On 02/13/2018 12:11 AM, bartc wrote:
>>
>>>> Did you?
>>>
>>> Yes, nice and simple.
>>
>> You must have a perverse idea of what is simple.
> 
> There is a set of instructions to follow.  Follow these, and you should
> have the C2 compiler.  I have not followed them myself (I am totally
> uninterested in having a C2 compiler - at least at this stage).
> Installing cygwin on Windows is not a difficult task, nor is installing
> these packages (you click them from the list in the cygwin installer).
> The instructions here are simple in that the list of requirements is
> short and complete - you don't have to think for yourself.

Do you ever stop to think about why exactly you need to have all those 
things? Or do you just accept it? In which case the next person to build 
on the result will add even more layers, until it grinds to a halt.

According to BGB's post, that can already happen.

Also, have you ever had to take over someone else's messy project, and 
the first thing you want to do is tidy it up, get rid of all the flab, 
the inessential dependencies, and streamline it, while retaining the 
essence of what it is intended to do?

The end result will be smaller, might run much more quickly and with 
less memory, and can be easier to subsequently maintain.

Or is your attitude that you have enough spare resources to run it as it 
is (or you just buy a bigger machine), so to hell with it?

A compiler is just a program like any other. If it's written in C, then 
you don't NEED any more tools than is needed for Hello World, especially 
if it's just for building, not developing, someone else's source code.

This is why you should be asking questions.

> If you are making a language that is a reasonable fit for llvm, then why
> not use it?  Rather than spending months making a limited little code
> generator for a single processor on a single OS, you can get a big,
> powerful system for free, with vastly more features.  Sure, it might
> take you a week to read through the documentation and play around with
> it - but it is a week, not months, and the result is far beyond what you
> would achieve in years.

If LLVM was that good then there would be hundreds of new languages all 
effortlessly developed in a month.

Actually, if it was that good, taking care of every aspect of developing 
a new language, why should it take any time at all? You just feed in a 
grammar and out comes a new compiler within a few seconds. After all 
most of the necessary components will already exist.

Why have people even both bothered with independent projects such as 
Pelles C and Tiny C? Or, perhaps, it's not quite that simple.

If you were paying someone a salary to develop a small language, it 
might just be the case that doing it from scratch (or modifying an 
existing one as I tend to start) might cost you less than battling with 
an incalcitrant development system with its own costs in extra resources.

Anyway I do it because I get a kick out of it. If I can create, 
single-handed and from scratch, a compiler which is 0.5% the size of 
clang, small enough and fast enough that it can compile itself in 0.04 
seconds, and capable of generating code that might only be 20% slower 
than the revered 'gcc' even with it's -O3 setting, then I think that is 
a pretty good achievement.

I know you are constantly trying to belittle my efforts, but I think 
what I'm doing is encouragement to others, who may otherwise be daunted 
by such a task or who may be led to believe that this stuff is only 
possible with hugely complex tools.

----------------------------------------

Starting Interpreter...
Loading: card2.jpg
IMAGE: 1920 x 1080            # Compiled with:
time: 3.510                   # gcc/tdm 5.1.0 -m64 -O3

Starting Interpreter...
Loading: card2.jpg
IMAGE: 1920 x 1080
time: 4.180                   # My non-C non-optimising compiler

Starting Interpreter...
Loading: card2.jpg
IMAGE: 1920 x 1080
time: 3.405                   # MSVC 64-bit /O2

Starting Interpreter...
Loading: card2.jpg
IMAGE: 1920 x 1080
time: 6.690                   # Tiny C 64-bit

Starting Interpreter...
Loading: card2.jpg
IMAGE: 1920 x 1080
time: 1.290                   # My compiler plus one asm module


-- 
bartc

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

#126587

On Sun, 11 Feb 2018 11:18:56 +0000
bartc <bc@freeuk.com> wrote:

> You mean, the niche markets dominated by x86, x64 and the various ARM 
> processors? (And probably other such as powerpc, mips and alpha, but
> I don't know what's what these days.)
> 
> (How many devices is it that Java runs on?)

I mean niche markets like the AMD64 architecture locked with C# on
Windows, the ARM architecture locked with Java on Android, Go and even
more Rust traction is almost equal to zero.

https://www.tiobe.com/tiobe-index/


> Some links for C2 also seem to use names such as "int" and "uint32";
> I don't know if that's a different version or if they are
> alternatives.

I think the C2 language specification is a moving target which clearly
demonstrates a lack of programming experience from its author unable to
make pragmatic design choices.


> (My own language also has this pattern of types, and it allows
> different ways of specifying the same type: "int", "i32", "int32".
> Adding aliases isn't very difficult. I don't use "i32" much excepted
> in generated code where it keeps things compact.)

So you made the same mistakes. Too many dreams but the reality is
harsh.


[quote]
> What, calling C functions from another language? Dozens of languages 
> already do that and have done so for a long time. I've been doing it 
> from mine for 25 years. I'm still doing it now.
[/quote]

Apart from C++, almost all programming languages failed to get traction
from programmers to call C libraries because it doesn't worth the
effort.


[quote]
> If there are complications, it's /because/ of C being the way it is. 
> (How big is 'long' again? What padding is there between those two
> struct members? What exactly is type T which is defined in two
> different typedefs in conditional blocks, in terms of a further type
> U which appears to be macro call?)
[/quote]

Is it so hard to call symbols inside an ELF object? Why is it so easy
for the C programming language? Why is it so easy to call assembly
routines from C? I assume Dennis M. RITCHIE made pragmatic choices for
the C design.

 
> No, only every so often. C already has C89, C99 and C11 versions, but 
> those haven't really changed much (just made it a PITA to write 
> compilers with, for a low-level language, advanced features out of 
> keeping with the rest of the language.).

It's just a PITA for YOU. Actually many successful compilers are written
in C.


> One of the C2 aims is specifically not to be more advanced, or do any 
> more, just do what C does but in a more modern way.

A modern way is a successful way but I believe C2 isn't very successful.


> (Modules replacing headers for example, but the build model I've seen 
> for it looks complicated.)

It's a complete mess! :-)

Perhaps the author should try to write a basic assembler first to master
the ABI.

-- 
GOTHIER Nathan

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

#126588

On 11/02/2018 23:00, GOTHIER Nathan wrote:
> On Sun, 11 Feb 2018 11:18:56 +0000

>> (My own language also has this pattern of types, and it allows
>> different ways of specifying the same type: "int", "i32", "int32".
>> Adding aliases isn't very difficult. I don't use "i32" much excepted
>> in generated code where it keeps things compact.)
> 
> So you made the same mistakes. Too many dreams but the reality is
> harsh.

What are the mistakes? The requirement at this level of language is to 
have signed/unsigned integer types of 8/16/32/64-bit widths to match 
typical hardware; how else would you do it?

Stick with the C model? I think everyone agrees that's a little messy. 
Looking only at unsigned types, here are some ways they might be 
encountered (only 64-bits have been given the full treatment):

8-bit   char[if unsigned], unsigned char, uint8_t

16-bit  unsigned short [IF short is 16 bits], uint16_t, unsigned int
         [when int is 16 bits]

32-bit  unsigned [if 32-bits], unsigned int [if 32 bits], uint32_t,
         unsigned long [if 32 bits], unsigned long int

64-bit  unsigned long [if 64 bits], uint64_t, unsigned long long,
         unsigned long long int, unsigned long int, long unsigned long,
         long int unsigned long, int unsigned long long, unsigned int
         long long, long unsigned int [if 64], ....

What about print specifiers (assuming int is 32 bits):

32-bit  unsigned int: %u
         unsigned long: %lu
         uint32_t: PRIu32 (as a whole string to be incorporated)

64-bit  unsigned long: %lu
         unsigned long long: %llu
         uint64_t: PRIu64

How about tabulating the main int types:

char       typically 8 bits
short      16 bits
int        32 bits
long       ?? bits
long long  64 bits

There are four main sizes of int, but FIVE main int types. And all of 
them could in theory be of any size provided the sizes are in this 
order, and some are of the minimum width required.

I think if mistakes have been made, we all know which language made them.

> [quote]
>> What, calling C functions from another language? Dozens of languages
>> already do that and have done so for a long time. I've been doing it
>> from mine for 25 years. I'm still doing it now.
> [/quote]
> 
> Apart from C++, almost all programming languages failed to get traction
> from programmers to call C libraries because it doesn't worth the
> effort.

Every programming language that works with Windows /has/ to be able to 
call C functions, because the OS's API (or much of it) is in C terms. It 
will be similar with Unix, probably more so as it's not implemented also 
in C++, CLI (or is it CIL), C# etc.

> Is it so hard to call symbols inside an ELF object? Why is it so easy
> for the C programming language?

The symbols aren't the problem. It is because those symbols are C 
functions whose interface is defined in C terms. /That's/ the problem.

> Why is it so easy to call assembly
> routines from C?

Is it?

Try calling an x64 function which takes a 128-bit struct passed in 
registers rax and rsi (low/high halves).

They're only easy to call if they use the platform ABI. On 32-bit x86, 
that wasn't standardised.

> I assume Dennis M. RITCHIE made pragmatic choices for
> the C design.
He has to be cut some slack because he did it in 1970. But even 10 years 
later, nothing was done about what must by then have been obviously poor 
design choices, at a time when it would have been much easier.


> It's just a PITA for YOU. Actually many successful compilers are written
> in C.

You mean, for C? And have you asked the writers how much of a PITA it 
was to implement every new thing in C99 and C11? How long did it take?

> 
>> (Modules replacing headers for example, but the build model I've seen
>> for it looks complicated.)
> 
> It's a complete mess! :-)
> 
> Perhaps the author should try to write a basic assembler first to master
> the ABI.

Yeah. The implementation looks horrendous. But many of the ideas seem sound.

-- 
bartc

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

#126592

On Mon, 12 Feb 2018 00:59:07 +0000
bartc <bc@freeuk.com> wrote:

> What are the mistakes? The requirement at this level of language is
> to have signed/unsigned integer types of 8/16/32/64-bit widths to
> match typical hardware; how else would you do it?

Fixed size types lack of implementation flexibility which made the C
programming language portable on many architectures. A requirement
for a programming language is to offer at least one integer type
capable to store values inside a minimal well defined range (e.g.
[-100, +100]). Providing more integer types enables the programmer to
improve the computation speed where it is possible (e.g. using short
instead of long).


> Stick with the C model? I think everyone agrees that's a little
> messy. Looking only at unsigned types, here are some ways they might
> be encountered (only 64-bits have been given the full treatment):
> 
> 8-bit   char[if unsigned], unsigned char, uint8_t
> 
> 16-bit  unsigned short [IF short is 16 bits], uint16_t, unsigned int
>          [when int is 16 bits]
> 
> 32-bit  unsigned [if 32-bits], unsigned int [if 32 bits], uint32_t,
>          unsigned long [if 32 bits], unsigned long int
> 
> 64-bit  unsigned long [if 64 bits], uint64_t, unsigned long long,
>          unsigned long long int, unsigned long int, long unsigned
> long, long int unsigned long, int unsigned long long, unsigned int
>          long long, long unsigned int [if 64], ....
> 
> What about print specifiers (assuming int is 32 bits):
> 
> 32-bit  unsigned int: %u
>          unsigned long: %lu
>          uint32_t: PRIu32 (as a whole string to be incorporated)
> 
> 64-bit  unsigned long: %lu
>          unsigned long long: %llu
>          uint64_t: PRIu64

I agree C type specifiers are messy and not concise. However it is
possible to make them concise with typedef (e.g. "ulong_t" instead
of "unsigned long int").


> How about tabulating the main int types:
> 
> char       typically 8 bits
> short      16 bits
> int        32 bits
> long       ?? bits
> long long  64 bits
> 
> There are four main sizes of int, but FIVE main int types. And all of 
> them could in theory be of any size provided the sizes are in this 
> order, and some are of the minimum width required.
> 
> I think if mistakes have been made, we all know which language made
> them.

All programming languages made mistakes according the their design
choices.

 
> Every programming language that works with Windows /has/ to be able
> to call C functions, because the OS's API (or much of it) is in C
> terms. It will be similar with Unix, probably more so as it's not
> implemented also in C++, CLI (or is it CIL), C# etc.

I disagree, there is no C in DLL or EXE.


> The symbols aren't the problem. It is because those symbols are C 
> functions whose interface is defined in C terms. /That's/ the problem.

Wrong! There is no C function in ELF, only symbols corresponding to
assembly labels (i.e. memory addresses).

 
> > Why is it so easy to call assembly
> > routines from C?
> 
> Is it?

Yes.


> Try calling an x64 function which takes a 128-bit struct passed in 
> registers rax and rsi (low/high halves).
> 
> They're only easy to call if they use the platform ABI. On 32-bit
> x86, that wasn't standardised.

Operating systems aren't standardised, why do you expect they all
conform to the same ABI?


> He has to be cut some slack because he did it in 1970. But even 10
> years later, nothing was done about what must by then have been
> obviously poor design choices, at a time when it would have been much
> easier.

I think his choices were pretty good since the wide use of C.


> You mean, for C? And have you asked the writers how much of a PITA it 
> was to implement every new thing in C99 and C11? How long did it take?

Many programming languages implementors used Yacc and Lex tools to build
easily their compiler, just to avoid the PITA with a bad design
(grammar defects).


> Yeah. The implementation looks horrendous. But many of the ideas seem
> sound.

Marketing sells sophisms but not scientific solutions.

-- 
GOTHIER Nathan

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

#126594

On 12/02/2018 11:29, GOTHIER Nathan wrote:
> On Mon, 12 Feb 2018 00:59:07 +0000
> bartc <bc@freeuk.com> wrote:
> 
>> What are the mistakes? The requirement at this level of language is
>> to have signed/unsigned integer types of 8/16/32/64-bit widths to
>> match typical hardware; how else would you do it?
> 
> Fixed size types lack of implementation flexibility which made the C
> programming language portable on many architectures. A requirement
> for a programming language is to offer at least one integer type
> capable to store values inside a minimal well defined range (e.g.
> [-100, +100]). Providing more integer types enables the programmer to
> improve the computation speed where it is possible (e.g. using short
> instead of long).
That's what Ada is for. Doing this stuff properly takes a lot of work. C 
and C2 are both far simpler.

>> I think if mistakes have been made, we all know which language made
>> them.
> 
> All programming languages made mistakes according the their design
> choices.

My language used to allow int*8 (64 bits), and int:48 (48 bits), but I 
dropped that, even though it was appealing, in the interests of making 
it simpler. Now int*8 is just written as int64 (or colloquially dint) 
and int:48 is not possible.

> I disagree, there is no C in DLL or EXE.
> 
> 
>> The symbols aren't the problem. It is because those symbols are C
>> functions whose interface is defined in C terms. /That's/ the problem.
> 
> Wrong! There is no C function in ELF, only symbols corresponding to
> assembly labels (i.e. memory addresses).

You keep saying this. But you don't just call a label:

    call printf

There are arguments to be passed, and values to be returned. That 
information is documented in C terms. The mechanics might be stipulated 
by the platform, but before that, you need to understand what the 
parameters are. And that's where C gets in the way.

> I think his choices were pretty good since the wide use of C.

That's why most new developments have dropped the worst ideas. (Except 
C++ which takes the worst of C, and combines it with the worst of C++.)

>> You mean, for C? And have you asked the writers how much of a PITA it
>> was to implement every new thing in C99 and C11? How long did it take?
> 
> Many programming languages implementors used Yacc and Lex tools to build
> easily their compiler, just to avoid the PITA with a bad design
> (grammar defects).

Lexing and parsing are the simplest, most trivial parts of a compiler.

-- 
bartc

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

#126598

On 12/02/18 13:18, bartc wrote:
> On 12/02/2018 11:29, GOTHIER Nathan wrote:
>> On Mon, 12 Feb 2018 00:59:07 +0000
>> bartc <bc@freeuk.com> wrote:

>>
>>> The symbols aren't the problem. It is because those symbols are C
>>> functions whose interface is defined in C terms. /That's/ the problem.
>>
>> Wrong! There is no C function in ELF, only symbols corresponding to
>> assembly labels (i.e. memory addresses).
> 
> You keep saying this. But you don't just call a label:
> 
>    call printf
> 
> There are arguments to be passed, and values to be returned. That
> information is documented in C terms. The mechanics might be stipulated
> by the platform, but before that, you need to understand what the
> parameters are. And that's where C gets in the way.
> 

The ABI specifies the way the arguments are passed and values returned.
 ABI's are not C specific - but C types are simple enough that they
correspond directly to the sorts of data passed here.  The fact the C
standards don't give precise values for things like the size of "int" or
the padding of structs is irrelevant - the ABI gives those details.  C
is not "getting in the way" - it is just letting you have a more
convenient description than saying "the function foo takes a 32-bit
unsigned integer in r0 and a pointer to an array of 8-bit data in r1".

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

#126599

On 12/02/2018 14:27, David Brown wrote:
> On 12/02/18 13:18, bartc wrote:
>> On 12/02/2018 11:29, GOTHIER Nathan wrote:
>>> On Mon, 12 Feb 2018 00:59:07 +0000
>>> bartc <bc@freeuk.com> wrote:
> 
>>>
>>>> The symbols aren't the problem. It is because those symbols are C
>>>> functions whose interface is defined in C terms. /That's/ the problem.
>>>
>>> Wrong! There is no C function in ELF, only symbols corresponding to
>>> assembly labels (i.e. memory addresses).
>>
>> You keep saying this. But you don't just call a label:
>>
>>     call printf
>>
>> There are arguments to be passed, and values to be returned. That
>> information is documented in C terms. The mechanics might be stipulated
>> by the platform, but before that, you need to understand what the
>> parameters are. And that's where C gets in the way.
>>
> 
> The ABI specifies the way the arguments are passed and values returned.
>   ABI's are not C specific - but C types are simple enough that they
> correspond directly to the sorts of data passed here.  The fact the C
> standards don't give precise values for things like the size of "int" or
> the padding of structs is irrelevant - the ABI gives those details.  C
> is not "getting in the way" - it is just letting you have a more
> convenient description than saying "the function foo takes a 32-bit
> unsigned integer in r0 and a pointer to an array of 8-bit data in r1".

20 years ago I was using a jpeg library in a .dll, which may or may not 
have been written in C, but the header file it came with was. One of the 
structs used was a 20KB monster, of which I only needed a handful of 
fields.

After I finished with it, my version looked like this (notice the size 
of the first field)

  type jpeg_properties=record
     [19966]byte padding             !skip complicated jpeg stuff
     int16       jfif_app0_units     !19966
     int16       jfif_app0_xdensity  !19968
     int16       jfif_app0_ydensity  !19970
     ichar       jpeg_comment        !19972
     int         jpeg_comment_size   !19976
     int         padding2            !19980, total size 19984
  end

But only after messing around with a C program to determine and 
double-check all those offsets and sizes.

This was also for x86, 32-bits, where a variety of call conventions were 
in use.

A universal struct description shouldn't need to depend on using an 
algorithm to determine offsets and padding. Or the size of a field.

-- 
bartc

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

#126601

On 12/02/18 16:19, bartc wrote:
> On 12/02/2018 14:27, David Brown wrote:
>> On 12/02/18 13:18, bartc wrote:
>>> On 12/02/2018 11:29, GOTHIER Nathan wrote:
>>>> On Mon, 12 Feb 2018 00:59:07 +0000
>>>> bartc <bc@freeuk.com> wrote:
>>
>>>>
>>>>> The symbols aren't the problem. It is because those symbols are C
>>>>> functions whose interface is defined in C terms. /That's/ the problem.
>>>>
>>>> Wrong! There is no C function in ELF, only symbols corresponding to
>>>> assembly labels (i.e. memory addresses).
>>>
>>> You keep saying this. But you don't just call a label:
>>>
>>>     call printf
>>>
>>> There are arguments to be passed, and values to be returned. That
>>> information is documented in C terms. The mechanics might be stipulated
>>> by the platform, but before that, you need to understand what the
>>> parameters are. And that's where C gets in the way.
>>>
>>
>> The ABI specifies the way the arguments are passed and values returned.
>>   ABI's are not C specific - but C types are simple enough that they
>> correspond directly to the sorts of data passed here.  The fact the C
>> standards don't give precise values for things like the size of "int" or
>> the padding of structs is irrelevant - the ABI gives those details.  C
>> is not "getting in the way" - it is just letting you have a more
>> convenient description than saying "the function foo takes a 32-bit
>> unsigned integer in r0 and a pointer to an array of 8-bit data in r1".
> 
> 20 years ago I was using a jpeg library in a .dll, which may or may not
> have been written in C, but the header file it came with was. One of the
> structs used was a 20KB monster, of which I only needed a handful of
> fields.
> 
> After I finished with it, my version looked like this (notice the size
> of the first field)
> 
>  type jpeg_properties=record
>     [19966]byte padding             !skip complicated jpeg stuff
>     int16       jfif_app0_units     !19966
>     int16       jfif_app0_xdensity  !19968
>     int16       jfif_app0_ydensity  !19970
>     ichar       jpeg_comment        !19972
>     int         jpeg_comment_size   !19976
>     int         padding2            !19980, total size 19984
>  end
> 
> But only after messing around with a C program to determine and
> double-check all those offsets and sizes.
> 
> This was also for x86, 32-bits, where a variety of call conventions were
> in use.
> 
> A universal struct description shouldn't need to depend on using an
> algorithm to determine offsets and padding. Or the size of a field.
> 

The reality of C type sizes, paddings, alignments, etc., is extremely
simple on almost all systems.  It is not the same on all systems, and
there are some odd-bod targets (mostly either very old, small embedded
systems, or niche devices) - thus the standards are flexible.  But on
any system you will ever meet, you will have "char" of 8-bit, "short" of
16-bit, "int" either 16-bit or 32-bit, "long" either 32-bit or 64-bit,
"long long" of 64-bit.  All signed types will be two's complement.
Pointers are either 32-bit or 64-bit.  "float" is 32-bit IEEE, "double"
is 64-bit IEEE.  Byte order is either fully little-endian or fully
big-endian.  Alignment of types (and therefore struct padding) is on
natural boundaries, usually with a maximum alignment (for example, on a
32-bit cpu, anything over 4 bytes might be 4 byte aligned).

This is /not/ rocket science.  It is not some evil conspiracy to cause
you confusion.  It is quite simple, and follows logical rules.  ABI's
cover this, and also calling conventions.  For most processors, the ABI
is set out sensibly, documented, and is followed by all compilers (C and
otherwise) and OS's.  Some processors have a couple of different ABI's,
optimised for small static systems (like dedicated embedded systems) or
for dynamic memory layouts (for general-purpose OS's) - usually that
only affects calling conventions and register usage, not sizes or
alignments.

The exception is the x86 world, primarily Windows - where there are at
least a dozen different calling conventions.  Even there, sizes and
alignments are clear.  And you can hardly blame C for MS's total screw
up in this area.

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

#126603

On 12/02/2018 15:49, David Brown wrote:
> On 12/02/18 16:19, bartc wrote:

>> A universal struct description shouldn't need to depend on using an
>> algorithm to determine offsets and padding. Or the size of a field.
>>
> 
> The reality of C type sizes, paddings, alignments, etc., is extremely
> simple on almost all systems.

That's why 'int' has a size which is 16 bits or more. That's why 'long' 
is 32 bits or more. That's why int and long can be the same size, but be 
different types. That's why 'char' might be signed. Or unsigned. Or has 
a third kind of type which will be equivalent to signed or unsigned, but 
can be incompatible with both.

This is not what I call 'extremely' simple. Extremely simple would C2's 
i8, i16, i32 and i64, with no padding and with no alignment requirements.

> This is /not/ rocket science.  It is not some evil conspiracy to cause
> you confusion.  It is quite simple, and follows logical rules.

Some counter examples; first from WinAPI:

   typedef struct tagBITMAPFILEHEADER {
     WORD  bfType;
     DWORD bfSize; ....

The 32-bit DWORD here is misaligned.

The next is clock_t which has already been recently discussed at length, 
in one case defined on top of several layers of typedefs and macros, 
some conditional. (The problem being to determine the type and width in 
order to duplicate that type elsewhere.)

This is a declaration from MSVC's stdio.h:

   _Check_return_opt_ _CRT_NONSTDC_DEPRECATE(_fcloseall) _CRTIMP int
      __cdecl fcloseall(void);

I believe it is a function declaration with four lots of attributes. 
(Can I just ignore them? I don't know.)

And a similar one from mingw's stdio.h:

extern
   __attribute__((__format__ (gnu_printf, 1, 2))) __MINGW_ATTRIB_NONNULL(1)
   int __cdecl __mingw_printf(const char * __restrict__ , ... ) 
__MINGW_NOTHROW;

This from another MS header; what are those _dev_t and _ino_t types:

   struct _stat32i64 {
         _dev_t     st_dev;
         _ino_t     st_ino;

I can't find the example of a struct where the first 6 members have 
types which are 5 different typedefs. The point is needless typedefs and 
having to hunt down those 'extremely simple' types that they correspond to.

So it is nowhere near as straightforward as you say.

I've been battling with this stuff since the earlier nineties (when I 
first started using C functions).

I don't think YOU can say it is simple if you've predominately been 
using it from C or C++.

-- 
bartc

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

#126609

On 02/13/2018 06:16 AM, bartc wrote:
> On 12/02/2018 15:49, David Brown wrote:
>> On 12/02/18 16:19, bartc wrote:
> 
>>> A universal struct description shouldn't need to depend on using an
>>> algorithm to determine offsets and padding. Or the size of a field.
>>>
>>
>> The reality of C type sizes, paddings, alignments, etc., is extremely
>> simple on almost all systems.
> 
> That's why 'int' has a size which is 16 bits or more. That's why 'long'
> is 32 bits or more. That's why int and long can be the same size, but be
> different types. That's why 'char' might be signed. Or unsigned. Or has
> a third kind of type which will be equivalent to signed or unsigned, but
> can be incompatible with both.
> 
> This is not what I call 'extremely' simple. Extremely simple would C2's
> i8, i16, i32 and i64, with no padding and with no alignment requirements.
> 
>> This is /not/ rocket science.  It is not some evil conspiracy to cause
>> you confusion.  It is quite simple, and follows logical rules.
> 
> Some counter examples; first from WinAPI:
> 
>     typedef struct tagBITMAPFILEHEADER {
>       WORD  bfType;
>       DWORD bfSize; ....
> 
> The 32-bit DWORD here is misaligned.
> 
> The next is clock_t which has already been recently discussed at length,
> in one case defined on top of several layers of typedefs and macros,
> some conditional. (The problem being to determine the type and width in
> order to duplicate that type elsewhere.)
> 
> This is a declaration from MSVC's stdio.h:
> 
>     _Check_return_opt_ _CRT_NONSTDC_DEPRECATE(_fcloseall) _CRTIMP int
>        __cdecl fcloseall(void);
> 
> I believe it is a function declaration with four lots of attributes.
> (Can I just ignore them? I don't know.)

As David said, you can hardly blame C for Microsoft's total screw up in 
this area.

On Linux and Solaris we have

extern int fcloseall (void);

-- 
Ian.
-- 
Ian.

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

#126620

On 12/02/18 18:16, bartc wrote:
> On 12/02/2018 15:49, David Brown wrote:
>> On 12/02/18 16:19, bartc wrote:
> 
>>> A universal struct description shouldn't need to depend on using an
>>> algorithm to determine offsets and padding. Or the size of a field.
>>>
>>
>> The reality of C type sizes, paddings, alignments, etc., is extremely
>> simple on almost all systems.
> 
> That's why 'int' has a size which is 16 bits or more. That's why 'long' 
> is 32 bits or more. That's why int and long can be the same size, but be 
> different types. That's why 'char' might be signed. Or unsigned. Or has 
> a third kind of type which will be equivalent to signed or unsigned, but 
> can be incompatible with both.

You skipped the bit where I noted that these are fixed on any given target.

> 
> This is not what I call 'extremely' simple. Extremely simple would C2's 
> i8, i16, i32 and i64, with no padding and with no alignment requirements.
> 

No padding and no alignment means poor performance - and for some 
processors, it means bus errors.

I would be quite happy with APIs using <stdint.h> types like int32_t and 
uint64_t.  That would make sense to me.  But standard C types seem to 
work fine for just about everyone except you, so they can't be /that/ bad.

>> This is /not/ rocket science.  It is not some evil conspiracy to cause
>> you confusion.  It is quite simple, and follows logical rules.
> 
> Some counter examples; first from WinAPI:
> 
>    typedef struct tagBITMAPFILEHEADER {
>      WORD  bfType;
>      DWORD bfSize; ....
> 
> The 32-bit DWORD here is misaligned.

And whose fault is that?  C's fault - or Microsoft's?

> 
> The next is clock_t which has already been recently discussed at length, 
> in one case defined on top of several layers of typedefs and macros, 
> some conditional. (The problem being to determine the type and width in 
> order to duplicate that type elsewhere.)

Yes, you made an amazing confusion out of clock_t.

> 
> This is a declaration from MSVC's stdio.h:
> 
>    _Check_return_opt_ _CRT_NONSTDC_DEPRECATE(_fcloseall) _CRTIMP int
>       __cdecl fcloseall(void);
> 

Whose fault is it that there are different kinds of calling conventions 
in the Windows world?  That is what the "__cdecl" part is for.

I don't know what all the other bits are (I am not familiar with C 
programming with the Windows API, or using MSVC), but they look like 
extra attributes used to improve static error checking.  To me, that's a 
good thing.  Maybe you think it is better to let programmers make their 
mistakes without giving them any help.  These sorts of extra check 
attributes or extensions are not part of the function call ABI, they are 
a help for the tool.  And one of the wonders of C is that - using macros 
- you can skip these if your tool does not support them.

> I believe it is a function declaration with four lots of attributes. 
> (Can I just ignore them? I don't know.)

I have never looked at one of MSVC's header files, and /I/ can make a 
solid guess about most of these attributes.  I can also make a good 
guess where to find out more details - MS's developer websites, or just 
use google.  How is it /possible/ to be so wilfully, stubbornly and 
determinedly ignorant as you are?

> 
> And a similar one from mingw's stdio.h:
> 
> extern
>    __attribute__((__format__ (gnu_printf, 1, 2))) __MINGW_ATTRIB_NONNULL(1)
>    int __cdecl __mingw_printf(const char * __restrict__ , ... ) 
> __MINGW_NOTHROW;

Like the declaration above, that contains the calling convention (again, 
MS is to blame for that necessity), and a variety of attributes to 
improve static error checking.  gcc (and clang) will check that the 
format string in printf calls matches the parameters, which is an 
extremely helpful feature.

> 
> This from another MS header; what are those _dev_t and _ino_t types:

Look them up.

> 
>    struct _stat32i64 {
>          _dev_t     st_dev;
>          _ino_t     st_ino;
> 
> I can't find the example of a struct where the first 6 members have 
> types which are 5 different typedefs. The point is needless typedefs and 
> having to hunt down those 'extremely simple' types that they correspond to.

If you don't understand the point of typedefs, I'd recommend going back 
to a beginners course in C programming.

> 
> So it is nowhere near as straightforward as you say.
> 
> I've been battling with this stuff since the earlier nineties (when I 
> first started using C functions).

You have been battling with it all right - you have never spent five 
minutes trying to understand it.  You declared it to be wrong in the 
early nineties when you first looked at it, and have spend the next 
three decades trying to justify that conclusion to yourself.

> 
> I don't think YOU can say it is simple if you've predominately been 
> using it from C or C++.
> 

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

#126622

On 12/02/2018 21:37, David Brown wrote:
> On 12/02/18 18:16, bartc wrote:

>> The 32-bit DWORD here is misaligned.
> 
> And whose fault is that?  C's fault - or Microsoft's?

I'm talking about APIs specified in C. They are necessarily outside the 
language, but the language allows that ambiguity. If padding and 
alignment don't need to be considered then the DWORD is at offset +0002 
and it would be correct.

(And actually, on x86, alignment is not crucial. What's crucial is 
creating an exact duplicate of that struct in an different language.)

> Yes, you made an amazing confusion out of clock_t.

Remind me again what the type was. How hard is it to just stipulate it 
as int32 or int64 and be done with it. And all those typedefs and macros 
were real.

> Whose fault is it that there are different kinds of calling conventions 
> in the Windows world?

Again, this is what you get in APIs. C is not as ideal a universal 
format for specifying interfaces as you seem to think.

> I have never looked at one of MSVC's header files, and /I/ can make a 
> solid guess about most of these attributes.  I can also make a good 
> guess where to find out more details - MS's developer websites, or just 
> use google.  How is it /possible/ to be so wilfully, stubbornly and 
> determinedly ignorant as you are?

Listen: YOU use C. YOU can just use:

   #include <windows.h>

and be done with it. It's all done for you (by those 500,000 lines of 
headers).

When you've written a major application around Win32 API in a C 
equivalent language without benefit of windows.h, then see if you still 
think it's easy, and everyone else who disagrees is ignorant.

Oh, and try doing it without the internet.

>> This from another MS header; what are those _dev_t and _ino_t types:
> 
> Look them up.

We've been through this. It's a hunting exercise trawling sub-headers 
and subdirectories. Or you have to create a dummy program, and compile 
with -E to get preprocessed output, and then trawl through /that/ to 
find out what they are.

That should not be necessary. (And when we discussed it last time, I 
said it should be possible to use such a library without needing a C 
compiler. So the -E option is out. And it should not be necessary to 
dive deep into system headers either. The docs should stand on their own.)

> If you don't understand the point of typedefs, I'd recommend going back 
> to a beginners course in C programming.

YOU seem incapable of understanding when typedefs are overused.

The first six members of a struct are just simple ints (some mix of 16 
and 32 bits, I don't recall), and there are FIVE different typedefs? 
Come on!

You probably think this is good coding:

  typedef struct {
      _dayno_t   day;
      _monthno_t month;
      _yearno_t  year;
  } rdate;

Can you even make a guess as to how many bytes such a struct has? Are 
those even integers?

Most people would prefer this:

  typedef struct {
      int8_t  day;
      int8_t  month;
      int16_t year;
  } rdate;

Total size, 32 bits. But I guess you're too ignorant to understand why 
something like this is better.

>> I've been battling with this stuff since the earlier nineties (when I 
>> first started using C functions).
> 
> You have been battling with it all right - you have never spent five 
> minutes trying to understand it.  You declared it to be wrong in the 
> early nineties when you first looked at it, and have spend the next 
> three decades trying to justify that conclusion to yourself.

Have you ever spent five minutes not doing this stuff with C, C++ or 
Python, where everyone else has already done all the hard work? Just you 
and the library, but no ready-made headers, interface files or bindings 
for your language.

-- 
bartc

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

#126637

On 02/13/2018 11:15 AM, bartc wrote:
> On 12/02/2018 21:37, David Brown wrote:
> 
>> Whose fault is it that there are different kinds of calling conventions
>> in the Windows world?
> 
> Again, this is what you get in APIs. C is not as ideal a universal
> format for specifying interfaces as you seem to think.

It is on sensible, programmer friendly platforms...

-- 
Ian.

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

#126647

On 13/02/2018 04:05, Ian Collins wrote:
> On 02/13/2018 11:15 AM, bartc wrote:
>> On 12/02/2018 21:37, David Brown wrote:
>>
>>> Whose fault is it that there are different kinds of calling conventions
>>> in the Windows world?
>>
>> Again, this is what you get in APIs. C is not as ideal a universal
>> format for specifying interfaces as you seem to think.
> 
> It is on sensible, programmer friendly platforms...

Perhaps you don't quite get what 'universal' means.

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

#126642

On 12/02/18 23:15, bartc wrote:
> On 12/02/2018 21:37, David Brown wrote:
>> On 12/02/18 18:16, bartc wrote:
> 
>>> The 32-bit DWORD here is misaligned.
>>
>> And whose fault is that?  C's fault - or Microsoft's?
> 
> I'm talking about APIs specified in C. They are necessarily outside the
> language, but the language allows that ambiguity. If padding and
> alignment don't need to be considered then the DWORD is at offset +0002
> and it would be correct.
> 
> (And actually, on x86, alignment is not crucial. What's crucial is
> creating an exact duplicate of that struct in an different language.)
> 

Alignment is crucial on x86 for performance, and for correctness in some
situations (like data shared between cpus, and in SIMD code).  But x86
cpus can access non-aligned data.

The problem here is MS's limited foresight when they made 16-bit Windows
and thought that 16-bit alignment was enough.  The fault lies solely and
squarely at their door.

The common way to handle structs like this, with non-natural alignment,
is to specify that it is a packed struct.  Different compilers have
different ways to declare that (and it would be nice if there were a
standardised method).

>> Yes, you made an amazing confusion out of clock_t.
> 
> Remind me again what the type was. How hard is it to just stipulate it
> as int32 or int64 and be done with it. And all those typedefs and macros
> were real.

No, we are not going to bring it up again.  Get yourself a proper IDE
and learn how to use it.  You choose to cripple your productivity and
come to c.l.c. to cry - it is /your/ problem.  Giving you advice or help
is pointless when you never take it, in case it spoils your
opportunities for whining.

> 
>> Whose fault is it that there are different kinds of calling
>> conventions in the Windows world?
> 
> Again, this is what you get in APIs. C is not as ideal a universal
> format for specifying interfaces as you seem to think.

It is a marvellous format, as long as it is used correctly.  MS does not
use it sensibly.  But even in Windows, it is better than any alternative
(when augmented by calling convention specifiers and other MS awkwardness).

> 
>> I have never looked at one of MSVC's header files, and /I/ can make a
>> solid guess about most of these attributes.  I can also make a good
>> guess where to find out more details - MS's developer websites, or
>> just use google.  How is it /possible/ to be so wilfully, stubbornly
>> and determinedly ignorant as you are?
> 
> Listen: YOU use C. YOU can just use:
> 
>   #include <windows.h>
> 
> and be done with it. It's all done for you (by those 500,000 lines of
> headers).

I don't /have/ <windows.h>.  (Not that there is a standard <windows.h>
file anyway).  I don't do C programming for Windows.  But I don't /need/
that to understand what that example function declaration does.

> 
> When you've written a major application around Win32 API in a C
> equivalent language without benefit of windows.h, then see if you still
> think it's easy, and everyone else who disagrees is ignorant.
> 

Only a complete moron would try, in this century, to write a major
application around the Win32 API in C - with or within <windows.h>.  It
is a stupid choice of language for the job, and programming directly to
the Win32 API as your main target is a masochistic idea.  The Win32 API
is there to provide a base - you write your widget toolkit or your
language wrappers on top of it if that is the kind of programming you
are doing.  Your "major app" is written in an appropriate language -
C++, C#, Java, Python, whatever - not in C, and not against the raw
Win32 API.  (The same applies to raw X API programming on *nix.  No sane
developer does it for anything but tiny little programs.)

I certainly never claimed that programming to the Win32 API in C is
easy.  All I said is that the sample function declaration you gave is
easy to understand.


> Oh, and try doing it without the internet.

Try beating your head against a tree as a method of chopping it down.
Go on - I'll wait.

> 
>>> This from another MS header; what are those _dev_t and _ino_t types:
>>
>> Look them up.
> 
> We've been through this. It's a hunting exercise trawling sub-headers
> and subdirectories. Or you have to create a dummy program, and compile
> with -E to get preprocessed output, and then trawl through /that/ to
> find out what they are.
> 
> That should not be necessary. (And when we discussed it last time, I
> said it should be possible to use such a library without needing a C
> compiler. So the -E option is out. And it should not be necessary to
> dive deep into system headers either. The docs should stand on their own.)

No one /cares/ what you think "should be necessary" - your perfect
simple world does not match reality, and it does not match the needs of
everyone else.

> 
>> If you don't understand the point of typedefs, I'd recommend going
>> back to a beginners course in C programming.
> 
> YOU seem incapable of understanding when typedefs are overused.
> 
> The first six members of a struct are just simple ints (some mix of 16
> and 32 bits, I don't recall), and there are FIVE different typedefs?
> Come on!
> 

Why is that a problem?  Honestly, I cannot see why you get so worked up
about this.

> You probably think this is good coding:
> 
>  typedef struct {
>      _dayno_t   day;
>      _monthno_t month;
>      _yearno_t  year;
>  } rdate;
> 
> Can you even make a guess as to how many bytes such a struct has? Are
> those even integers?

Does it matter?  If it does, then "sizeof" will give me the answer.

Perhaps "_dayno_t" is an enumerated type.  Perhaps these types are small
types for minimising memory usage (for large arrays, or for small
embedded systems).  Perhaps they are large types.  Perhaps the types are
used to make the code more flexible.  If more people used typedefs like
this, rather than hard-coding "int", "short", etc., then we'd have far
fewer problems like Y2K or Y2039, and a much easier job porting between
platforms.

C's typing system is very weak.  In languages with stronger typing,
giving these parts a different type would mean that the language (mostly
at compile time, possibly at run time) can spot mixups between the
types, and support nice, clear use of these types with automatic
conversions.  You don't get that in C (except by wrapping in structs),
but having specific type names can make the source code clearer.
Knowing that "x" is a "dayno_t" gives you far more useful information
than knowing it is an "int".

> 
> Most people would prefer this:
> 
>  typedef struct {
>      int8_t  day;
>      int8_t  month;
>      int16_t year;
>  } rdate;
> 
> Total size, 32 bits. But I guess you're too ignorant to understand why
> something like this is better.

/Sometimes/ it is better - sometimes not.  Sometimes unsigned types make
sense.  Sometimes you want small types like this, sometimes you want
bigger types that might be faster.  Sometimes you want enumerated types.
 Sometimes you want stronger types.

Usually when you think that one method of coding is better, it is
because you can't see beyond your own navel and imagine why other people
might do something different.

> 
>>> I've been battling with this stuff since the earlier nineties (when I
>>> first started using C functions).
>>
>> You have been battling with it all right - you have never spent five
>> minutes trying to understand it.  You declared it to be wrong in the
>> early nineties when you first looked at it, and have spend the next
>> three decades trying to justify that conclusion to yourself.
> 
> Have you ever spent five minutes not doing this stuff with C, C++ or
> Python, where everyone else has already done all the hard work? Just you
> and the library, but no ready-made headers, interface files or bindings
> for your language.
> 

In most of my C programming, I write virtually everything in the code.
I make little use of the C library.  On some of my systems I wrote all
the startup code - everything from the power-on reset up to the start of
main().  Yes, I have plenty of experience of working from scratch.

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

#126646

On 13/02/2018 09:32, David Brown wrote:
> On 12/02/18 23:15, bartc wrote:

>>   typedef struct {
>>       _dayno_t   day;
>>       _monthno_t month;
>>       _yearno_t  year;
>>   } rdate;

> Does it matter?  If it does, then "sizeof" will give me the answer.

sizeof won't tell you if those elements are signed, unsigned or even 
even integers.

This is what you will see as part of an API that you are trying to use 
from another language. To use sizeof you need to run a C compiler.

>> Have you ever spent five minutes not doing this stuff with C, C++ or
>> Python, where everyone else has already done all the hard work? Just you
>> and the library, but no ready-made headers, interface files or bindings
>> for your language.
>>
> 
> In most of my C programming, I write virtually everything in the code.
> I make little use of the C library.  On some of my systems I wrote all
> the startup code - everything from the power-on reset up to the start of
> main().  Yes, I have plenty of experience of working from scratch.

Writing from scratch is easy. The problem is interfacing with APIs 
written in another language, where not really designed to be used from 
another.

-- 
bartc

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

#126700

> Writing from scratch is easy. The problem is interfacing with APIs 
> written in another language, where not really designed to be used from 
> another.

It's very easy to write a C program that will give you the size,
signedness, and on some compilers alignment of a C typedef or
built-in type on the platform you are running it on.  For a given
machine, you only have to run it at most once per typedef, then
keep the output around for later reference, unless perhaps the API
changes (e.g. you can run 16-bit, 32-bit and 64-bit code on modern
x86 machines, depending on which version of which OS you boot).
You could probably write and run such a program much faster than
posting a complaint about having to do it.

Or, you could make a collection of *ALL* of the built-in C types
and typedefs you are likely to run in to (even if not all of them
are defined by C standards, you'll run into POSIX, UNIX, and various
other types also), and have the program spit out a complete list
of them on any new platform you encounter.  (Granted, it may take
some work to figure out at compile time if and where something like
dev_t or ino_t or goat_t is defined.)  Or just keep adding them as
you run into them.

It is not the responsibility of the OS writer to provide libraries
or headers to interface languages that haven't been designed yet
to the OS.  The specifications to write such libraries should be
available, but they don't have to be written so the implementer
doesn't have to do any work to get them into the form the implementor
wants.

The implementor may have to bend a little, also, in that there needs
to be some way to generate a call from the new language to the
provided OS libraries using proper linkage conventions (even if
it's some odd hack like "cdecl", or providing a library written
in assembly-language to bridge two incompatible calling conventions).

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

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

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

csiph-web