erik quanstrom wrote:
|> memory bug in Jörg Schilling's Bourne shell (likely developed only
|> on Solaris rooted) simply by compiling and starting it under
|> FreeBSD. And i have found stack read violations simply by running
|
|given cdrtools, this is not a surprise.
On November 29, 2015 3:41:45 AM CST, Vasudev Kamath
wrote:
>Ryan Gonzalez writes:
>
>>>That took compilation further but now it breaks at point 4 in your
>>>issue. I hope I won't encounter more new issues :-).
>>>
>>
>> Ah, yes, I completely forgot
Ryan Gonzalez writes:
>>That took compilation further but now it breaks at point 4 in your
>>issue. I hope I won't encounter more new issues :-).
>>
>
> Ah, yes, I completely forgot about that part. :/ Good luck with the
> rest of the compilation! You'll need it!
Yes indeed.
On Sun, Nov 29, 2015 at 07:57:58AM +0200, lu...@proxima.alt.za wrote:
>
> I remember using AutoCad 2.6 on an 8086 with a floating point
> accelerator and being impressed by the speed of its 3D rendering. I
> have no idea how AutoCad behaves these days, but faster rendering
> would imply
Not dogmatic. Just 38 years and I still believe small is beautify.
One interesting thing is that for the past twenty years new architectures have
been designed to run C code well. Just check out the papers a ISCA. Then why do
we have to have such complicated compilers to generate code for it.
On November 28, 2015 12:42:25 AM CST, da Tyga wrote:
>I have been following this discussion about the C compiler and can no
>longer stop myself from making a (snarky?) comment.
>
If you thing this is snarky, you've never visited the Final Fantasy XV board on
GameFAQs! ;)
Brantley wrote:
> One could argue that the Plan 9 C compiler lacks the modern optimizations
> that the other compilers have. This would be true. But I would argue that
> almost all of those optimizations are either not needed...
Note the "almost all" in there. It's important not to get
> I think the issue is trying to fix a broken problem. Perfect
> compatibility is pretty much impossible, but most attempts done to fix
> it just shift the pain to somewhere else. What's the quote about
> complexity not disappearing, just moving around?
Basically, increased CPU complexity
> One interesting thing is that for the past twenty years new
> architectures have been designed to run C code well. Just check out
> the papers a ISCA. Then why do we have to have such complicated
> compilers to generate code for it.
I'm pretty sure that you can lay that at C's door. Had
Ryan Gonzalez wrote:
> See
> https://bitbucket.org/plan9-from-bell-labs/9-cc/issues/1/problems-building-under-x64-linux
> for some tips on fixing various errors you may encounter, including this
> one. (I opened that issue like 8 months ago...)
>
> On Wed, Nov 25, 2015 at 11:10
Ryan Gonzalez writes:
> Try going to the top of mathi.h and putting:
>
> #undef isnan
> #undef isinf
>
> Stupid macros that don't look like macros.
That worked. Even I didn't realize those as macros. But now I land in
new error.
/usr/include/features.h:148:3: warning:
Hi Ryan,
Ryan Gonzalez writes:
> See
> https://bitbucket.org/plan9-from-bell-labs/9-cc/issues/1/problems-building-under-x64-linux
> for some tips on fixing various errors you may encounter, including
> this one. (I opened that issue like 8 months ago...)
I followed your
Try going to the top of mathi.h and putting:
#undef isnan
#undef isinf
Stupid macros that don't look like macros.
On November 27, 2015 10:50:20 AM CST, Vasudev Kamath
wrote:
>
>Hi Ryan,
>
>Ryan Gonzalez writes:
>> See
>>
On November 27, 2015 11:16:02 AM CST, Vasudev Kamath
wrote:
>Ryan Gonzalez writes:
>
>> Try going to the top of mathi.h and putting:
>>
>> #undef isnan
>> #undef isinf
>>
>> Stupid macros that don't look like macros.
>
>That worked. Even I didn't
On Fri, Nov 27, 2015 at 09:13:20AM +0100, Giacomo Tesio wrote:
>
> I know nothing about compilers, but actually gcc and clang dimension and
> complexity is astonishing.
It's not astonishing: it's research. They want to prove that a black
hole does exist. So they write a "model", a software
> What about ostensible crypto libraries that get their random numbers from
> Walmart?
Do they get those over the counter?
Lucio.
On Fri, Nov 27, 2015 at 03:07:30PM +0100, Giacomo Tesio wrote:
>
> Funny, but actually I was wondering if there is any subtle issue in the
> standards of the C language that makes it somehow hard to implement.
I guess it depends on what is the "standard". The naked C language is
(was) simple.
2015-11-27 13:42 GMT+01:00 :
> On Fri, Nov 27, 2015 at 09:13:20AM +0100, Giacomo Tesio wrote:
> >
> > I know nothing about compilers, but actually gcc and clang dimension and
> > complexity is astonishing.
>
> It's not astonishing: it's research. They want to prove that a
|How they ever got it going on a system with 64Kbytes of address space\
|, I'll never know.
Yeah!
--steffen
> Funny, but actually I was wondering if there is any subtle issue in the
> standards of the C language that makes it somehow hard to implement.
> For example I've met a few times weird implementations of libraries and
> frameworks dictated by broken standards: once they are in, they can never
>
Great point. And you actually don’t meet the minimum requirement for snarky
messages.
You argue the the large compilers are due to the increase in the complexity of
the specification and the complexities of generating code for the Intel
instruction set. To some extent you are correct. A modern
I have been following this discussion about the C compiler and can no
longer stop myself from making a (snarky?) comment.
The K standard for C was very much written when the C language was a
higher than assembler language for the PDP-11 (at least that's how I became
acquainted with it back in
arn...@skeeve.com wrote:
|> Alternative compilers, like tcc, only build C on very few architectures /
|> os with almost no optimization: they are much smaller, but still not
|> standard compliant.
|TCC compiles really fast, and it's (finally) good enough that I can use
|it for my personal
> memory bug in Jörg Schilling's Bourne shell (likely developed only
> on Solaris rooted) simply by compiling and starting it under
> FreeBSD. And i have found stack read violations simply by running
given cdrtools, this is not a surprise.
2015-11-27 0:21 GMT+01:00 Charles Forsyth :
>
> On 26 November 2015 at 23:08, Ryan Gonzalez wrote:
>
>> Holy crap, that's crazy. I built it in debug mode on Linux, but I don't
>> think it used that much. I only have 6 GB right now!
>
>
> You have to
> I know nothing about compilers, but actually gcc and clang dimension and
> complexity is astonishing.
> I've always thought that this is due to their desire to compile many
> different language optimized for many different OS and architectures on
> many different OS and architecture.
That is a
That copy of the compilers was changed quite a bit by someone else, and I
only belatedly realised that.
I'll try to resurrect that one, since it would help me keep the Plan 9 and
Inferno compilers in sync, as well.
On 25 November 2015 at 17:24, Vasudev Kamath wrote:
>
On 25 November 2015 at 17:10, Vasudev Kamath wrote:
> In file included from
> /home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include/lib9.h:9:0,
> from 9obj.c:5:
> /usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and
>
>> In file included from
>> /home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include/lib9.h:9:0,
>> from 9obj.c:5:
>> /usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and
>> _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
>> # warning
On November 26, 2015 6:10:43 AM CST, Charles Forsyth
wrote:
>On 25 November 2015 at 17:10, Vasudev Kamath
>wrote:
>
>> In file included from
>>
>/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include/lib9.h:9:0,
>>
On 26 November 2015 at 18:15, Ryan Gonzalez wrote:
> the only library on earth that makes me want to bang my head on the floor.
There must be others, surely. What about graphics libraries with APIs
designed for FORTRAN (no data structures)?
What about ostensible crypto
> the only library on earth that makes me want to bang my head on the floor.
>
You need to get out more
On November 26, 2015 3:56:44 PM CST, Charles Forsyth
wrote:
>On 26 November 2015 at 21:51, Charles Forsyth
>
>wrote:
>
>> On 26 November 2015 at 21:49, Ryan Gonzalez wrote:
>>
>>> All that is bad...but glibc is worse. The
On November 26, 2015 3:31:11 PM CST, Charles Forsyth
wrote:
>On 26 November 2015 at 18:15, Ryan Gonzalez wrote:
>
>> the only library on earth that makes me want to bang my head on the
>floor.
>
>
>There must be others, surely. What about graphics
On 26 November 2015 at 21:49, Ryan Gonzalez wrote:
> All that is bad...but glibc is worse. The issue is that you kinda *have*
> to use it,
true, very true.
On 26 November 2015 at 21:51, Charles Forsyth
wrote:
> On 26 November 2015 at 21:49, Ryan Gonzalez wrote:
>
>> All that is bad...but glibc is worse. The issue is that you kinda *have*
>> to use it,
>
>
> true, very true.
i remember glibc being my
>> I remember the time I was trying to build LLVM+Clang on Windows in debug
>> mode. Because...MinGW...I actually surpassed the file size limit when
>> linking Clang, so I had to rebuild EVERYTHING. Stupid thing took about an
>> hour each time.
>
>
> Ah. Debug mode. It took me a while to suspect:
On 26 November 2015 at 22:02, Ryan Gonzalez wrote:
> I remember the time I was trying to build LLVM+Clang on Windows in debug
> mode. Because...MinGW...I actually surpassed the file size limit when
> linking Clang, so I had to rebuild EVERYTHING. Stupid thing took about an
>
Clearly history is wrong. It would never be able to compile C in less than 18MB
(1/2 of clang’s text size). Therefor Unix didn’t really happen. It’s all been a
phone company conspiracy for world domination, like the NASA not really
putting a man on the moon. We were just *told* they had built
On 26 November 2015 at 23:08, Ryan Gonzalez wrote:
> Holy crap, that's crazy. I built it in debug mode on Linux, but I don't
> think it used that much. I only have 6 GB right now!
You have to remember that a C compiler is one of the largest, most complex
software components
On November 26, 2015 5:21:54 PM CST, Charles Forsyth
wrote:
>On 26 November 2015 at 23:08, Ryan Gonzalez wrote:
>
>> Holy crap, that's crazy. I built it in debug mode on Linux, but I
>don't
>> think it used that much. I only have 6 GB right now!
>
On November 26, 2015 4:30:32 PM CST, David du Colombier <0in...@gmail.com>
wrote:
>>> I remember the time I was trying to build LLVM+Clang on Windows in
>debug
>>> mode. Because...MinGW...I actually surpassed the file size limit
>when
>>> linking Clang, so I had to rebuild EVERYTHING. Stupid
Hi,
I'm trying to compile ken-cc from ¹. Its giving me following error
cc -c -m32 -g -O
-I/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include
-I/home/vasudev/Documents/C_programming/compilers/9-cc/include -DLINUX_386
-I../cmd/ 9obj.c
In file included from
See
https://bitbucket.org/plan9-from-bell-labs/9-cc/issues/1/problems-building-under-x64-linux
for some tips on fixing various errors you may encounter, including this
one. (I opened that issue like 8 months ago...)
On Wed, Nov 25, 2015 at 11:10 AM, Vasudev Kamath
wrote:
Ryan Gonzalez writes:
> See
> https://bitbucket.org/plan9-from-bell-labs/9-cc/issues/1/problems-building-under-x64-linux
> for some tips on fixing various errors you may encounter, including
> this one. (I opened that issue like 8 months ago...)
Thanks Ryan, I will follow
45 matches
Mail list logo