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

Groups > comp.lang.python > #57152 > unrolled thread

Python Front-end to GCC

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

Contents

  Python Front-end to GCC Philip Herron <herron.philip@googlemail.com> - 2013-10-20 10:56 -0700
    Re: Python Front-end to GCC victorgarcianet@gmail.com - 2013-10-20 15:10 -0700
      Re: Python Front-end to GCC John Nagle <nagle@animats.com> - 2013-10-22 23:48 -0700
        Re: Python Front-end to GCC Philip Herron <herron.philip@googlemail.com> - 2013-10-23 00:25 -0700
          Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-23 09:42 +0100
          Re: Python Front-end to GCC John Nagle <nagle@animats.com> - 2013-10-23 13:51 -0700
    Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-20 20:35 -0700
      Re: Python Front-end to GCC Steven D'Aprano <steve@pearwood.info> - 2013-10-21 07:46 +0000
        Re: Python Front-end to GCC Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-10-21 10:55 +0100
          Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-21 23:41 +0000
            Re: Python Front-end to GCC Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-10-22 10:14 +0100
              Re: Python Front-end to GCC Philip Herron <herron.philip@googlemail.com> - 2013-10-22 02:32 -0700
              Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-22 12:00 +0000
                Re: Python Front-end to GCC Chris Angelico <rosuav@gmail.com> - 2013-10-22 23:20 +1100
                  Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-22 17:27 +0000
                    Re: Python Front-end to GCC Chris Angelico <rosuav@gmail.com> - 2013-10-23 08:43 +1100
                Re: Python Front-end to GCC Dave Angel <davea@davea.name> - 2013-10-22 14:04 +0000
                  Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-22 15:22 +0000
                    Re: Python Front-end to GCC Grant Edwards <invalid@invalid.invalid> - 2013-10-22 15:39 +0000
                      Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-22 16:40 +0000
                        Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-22 17:50 +0100
                        Re: Python Front-end to GCC Chris Kaynor <ckaynor@zindagigames.com> - 2013-10-22 09:52 -0700
                          Re: Python Front-end to GCC albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-11-01 22:48 +0000
                        Re: Python Front-end to GCC Frank Miles <fpm@u.washington.edu> - 2013-10-22 16:53 +0000
                          Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-22 17:23 +0000
                            Re: Python Front-end to GCC Chris Kaynor <ckaynor@zindagigames.com> - 2013-10-22 10:35 -0700
                            Re: Python Front-end to GCC Neil Cerutti <neilc@norwich.edu> - 2013-10-22 17:37 +0000
                            Re: Python Front-end to GCC Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-10-22 18:37 +0100
                            Re: Python Front-end to GCC MRAB <python@mrabarnett.plus.com> - 2013-10-22 18:42 +0100
                            Re: Python Front-end to GCC Grant Edwards <invalid@invalid.invalid> - 2013-10-22 18:49 +0000
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 04:40 +0100
                            Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 04:55 -0700
                            Re: Python Front-end to GCC Dan Sommers <dan@tombstonezero.net> - 2013-10-25 12:55 +0000
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 15:18 +0100
                            Re: Python Front-end to GCC Ned Batchelder <ned@nedbatchelder.com> - 2013-10-25 10:35 -0400
                            Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 11:26 -0700
                              Re: Python Front-end to GCC Grant Edwards <invalid@invalid.invalid> - 2013-10-25 19:06 +0000
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 19:40 +0100
                            Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 11:45 -0700
                              Re: Python Front-end to GCC rusi <rustompmody@gmail.com> - 2013-10-25 11:59 -0700
                                Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 12:09 -0700
                                  Re: Python Front-end to GCC rusi <rustompmody@gmail.com> - 2013-10-25 12:15 -0700
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 20:02 +0100
                            Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 12:18 -0700
                              Re: Python Front-end to GCC John Nagle <nagle@animats.com> - 2013-10-26 14:31 -0700
                                Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-26 15:10 -0700
                                Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-27 15:14 -0700
                                  Re: Python Front-end to GCC rusi <rustompmody@gmail.com> - 2013-10-27 19:15 -0700
                                    Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-28 08:44 +0000
                                      Re: Python Front-end to GCC rusi <rustompmody@gmail.com> - 2013-10-28 02:31 -0700
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 20:36 +0100
                            Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 12:49 -0700
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 21:14 +0100
                            Re: Python Front-end to GCC Tim Delaney <timothy.c.delaney@gmail.com> - 2013-10-26 07:11 +1100
                            Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 13:29 -0700
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 21:36 +0100
                              Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-26 02:42 +0000
                                [OT] Re: Python Front-end to GCC Antoine Pitrou <solipsis@pitrou.net> - 2013-10-29 11:04 +0000
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 21:44 +0100
                            Re: Python Front-end to GCC Tim Delaney <timothy.c.delaney@gmail.com> - 2013-10-26 07:48 +1100
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 21:56 +0100
                            Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 14:02 -0700
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 22:11 +0100
                            Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 14:37 -0700
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 22:56 +0100
                            Re: Python Front-end to GCC Chris Angelico <rosuav@gmail.com> - 2013-10-26 13:36 +1100
                    Re: Python Front-end to GCC Neil Cerutti <neilc@norwich.edu> - 2013-10-22 17:15 +0000
                      Re: Python Front-end to GCC Grant Edwards <invalid@invalid.invalid> - 2013-10-22 18:58 +0000
                        Re: Python Front-end to GCC Grant Edwards <invalid@invalid.invalid> - 2013-10-22 20:26 +0000
                  Re: Python Front-end to GCC Grant Edwards <invalid@invalid.invalid> - 2013-10-22 15:36 +0000
                Re: Python Front-end to GCC Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-10-22 15:15 +0100
        Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-21 13:14 -0700
        Re: Python Front-end to GCC Ned Batchelder <ned@nedbatchelder.com> - 2013-10-21 16:29 -0400
          Re: Python Front-end to GCC rusi <rustompmody@gmail.com> - 2013-10-21 20:40 -0700
    Re: Python Front-end to GCC Philip Herron <herron.philip@googlemail.com> - 2013-10-21 04:08 -0700
      Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-21 13:26 -0700
        Re: Python Front-end to GCC Philip Herron <herron.philip@googlemail.com> - 2013-10-21 14:03 -0700
          Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-21 16:04 -0700
            Re: Python Front-end to GCC Piet van Oostrum <piet@vanoostrum.org> - 2013-10-21 23:45 -0400
              Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-21 21:24 -0700
                Re: Python Front-end to GCC Steven D'Aprano <steve@pearwood.info> - 2013-10-22 05:25 +0000
              Re: Python Front-end to GCC Dave Angel <davea@davea.name> - 2013-10-22 04:39 +0000
              Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-22 08:04 -0700
                Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-22 17:09 +0000
                Re: Python Front-end to GCC Piet van Oostrum <piet@vanoostrum.org> - 2013-10-22 13:20 -0400
              Re: Python Front-end to GCC Ned Batchelder <ned@nedbatchelder.com> - 2013-10-22 11:46 -0400
              Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-22 16:52 +0100
              Re: Python Front-end to GCC Benjamin Kaplan <benjamin.kaplan@case.edu> - 2013-10-22 09:03 -0700
              Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-22 10:50 -0700
                Re: Python Front-end to GCC rusi <rustompmody@gmail.com> - 2013-10-22 11:11 -0700
                Re: Python Front-end to GCC Neil Cerutti <neilc@norwich.edu> - 2013-10-22 18:18 +0000
                  Re: Python Front-end to GCC Piet van Oostrum <piet@vanoostrum.org> - 2013-10-22 15:20 -0400
                    Re: Python Front-end to GCC Neil Cerutti <neilc@norwich.edu> - 2013-10-22 19:27 +0000
                      Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-22 20:38 +0100
                        Re: Python Front-end to GCC Neil Cerutti <neilc@norwich.edu> - 2013-10-22 20:00 +0000
                    Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-22 20:32 +0100
              Re: Python Front-end to GCC Skip Montanaro <skip@pobox.com> - 2013-10-22 13:08 -0500
              Re: Python Front-end to GCC MRAB <python@mrabarnett.plus.com> - 2013-10-22 19:16 +0100
              Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-22 11:16 -0700
              Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-22 11:22 -0700
              Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-22 11:28 -0700
                Re: Python Front-end to GCC Piet van Oostrum <piet@vanoostrum.org> - 2013-10-22 18:11 -0400
                  Re: Python Front-end to GCC Chris Angelico <rosuav@gmail.com> - 2013-10-23 17:28 +1100
                Re: Python Front-end to GCC Grant Edwards <invalid@invalid.invalid> - 2013-10-22 22:47 +0000
              Re: Python Front-end to GCC Ned Batchelder <ned@nedbatchelder.com> - 2013-10-22 14:23 -0400
                Re: Python Front-end to GCC rusi <rustompmody@gmail.com> - 2013-10-22 11:40 -0700
                  Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-22 19:58 +0100
              Re: Python Front-end to GCC Ned Batchelder <ned@nedbatchelder.com> - 2013-10-22 14:40 -0400
                Re: Python Front-end to GCC alex23 <wuwei23@gmail.com> - 2013-10-23 11:36 +1000
                  Re: Python Front-end to GCC rusi <rustompmody@gmail.com> - 2013-10-22 21:04 -0700
                  Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-23 07:06 +0100
              Re: Python Front-end to GCC MRAB <python@mrabarnett.plus.com> - 2013-10-22 19:47 +0100
              Re: Python Front-end to GCC Ned Batchelder <ned@nedbatchelder.com> - 2013-10-22 13:56 -0400
              Re: Python Front-end to GCC Michael Torrie <torriem@gmail.com> - 2013-10-22 22:05 -0600
              Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-23 07:13 +0100
              Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-26 14:25 -0700
              Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-26 14:33 -0700
              Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-26 22:38 +0100
              Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-26 22:35 +0100
                Re: Python Front-end to GCC Grant Edwards <invalid@invalid.invalid> - 2013-10-28 14:21 +0000
                  Re: Python Front-end to GCC Chris Angelico <rosuav@gmail.com> - 2013-10-29 01:26 +1100
                    Re: Python Front-end to GCC Neil Cerutti <neilc@norwich.edu> - 2013-10-28 15:01 +0000
      Re: Python Front-end to GCC Antoine Pitrou <solipsis@pitrou.net> - 2013-10-22 08:55 +0000
        Re: Python Front-end to GCC Philip Herron <herron.philip@googlemail.com> - 2013-10-22 02:08 -0700
        Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-22 10:10 +0000
          Re: Python Front-end to GCC Antoine Pitrou <solipsis@pitrou.net> - 2013-10-22 15:51 +0000
      Re: Python Front-end to GCC Stefan Behnel <stefan_ml@behnel.de> - 2013-10-24 08:47 +0200
    Re: Python Front-end to GCC xDog Walker <thudfoo@gmail.com> - 2013-10-25 14:49 -0700
    Re: Python Front-end to GCC sharath.cs.smp@gmail.com - 2013-11-15 07:59 -0800

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

#57563

On 25/10/2013 21:48, Tim Delaney wrote:
> But OTOH, it can also be explained away entirely by (as you previously
> noted) the Dunning-Kruger effect, with the same uninformed responses
> trotted out to everything.

It was rusi who first mentioned this, I merely replied in my normal dead 
pan way.

Slight aside, I spelt your surname incorrectly a few minutes ago whilst 
replying elsewhere, I do apologise.

-- 
Python is the second best programming language in the world.
But the best has yet to be invented.  Christian Tismer

Mark Lawrence

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

#57564

>> But OTOH, it can also be explained away entirely by (as you previously
>> noted) the Dunning-Kruger effect, with the same uninformed responses
>> trotted out to everything.
>
> It was rusi who first mentioned this, I merely replied in my normal dead pan
> way.
>
> Slight aside, I spelt your surname incorrectly a few minutes ago whilst
> replying elsewhere, I do apologise.

What is this?  The circle-jerk list?  I make some points on the last
couple of threads and you all get bent-out of shape, then gather
around each other as if you're all in a cancer ward....

-- 
MarkJ
Tacoma, Washington

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

#57566

On 25/10/2013 22:02, Mark Janssen wrote:
>>> But OTOH, it can also be explained away entirely by (as you previously
>>> noted) the Dunning-Kruger effect, with the same uninformed responses
>>> trotted out to everything.
>>
>> It was rusi who first mentioned this, I merely replied in my normal dead pan
>> way.
>>
>> Slight aside, I spelt your surname incorrectly a few minutes ago whilst
>> replying elsewhere, I do apologise.
>
> What is this?  The circle-jerk list?  I make some points on the last
> couple of threads and you all get bent-out of shape, then gather
> around each other as if you're all in a cancer ward....
>

Will you please do yourself a favour and get a new dealer before you do 
some real damage, the batch you're currently on is definitely contaminated.

-- 
Python is the second best programming language in the world.
But the best has yet to be invented.  Christian Tismer

Mark Lawrence

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

#57569

On Fri, Oct 25, 2013 at 2:07 PM, Ned Batchelder <ned@nedbatchelder.com> wrote:
> (Offlist)
>
> Mark, these conversations would go much more smoothly if you would make
> direct statements about technical points.  Your messages are usually
> insinuating questions, or personal insults.

Yes, thank you.  That is correct.

> For example, you said:
>
>     Please give me the hex value for NaN so I can initialize with my array.
>
> I think what you meant by this was: "I don't think there is a hex value that
> represents NaN."  Why not say that?

Why?  Because I know there's not a hex value for NaN, otherwise it
would confuse the abstraction of what a computer is.  Any hex digit
you could attempt to obscure would be translatable as a number, and
therefore a contradiction.  Is that a good enough reason for ya?

> Then we could talk about your claim.

How about we talk about my claim with facts instead of attempts at
creating reality a la NovusOrdoSeclorum?

> You could even go so far as to admit that others might know things you
> don't, and ask, "is there a hex value that represents NaN, I didn't realize
> there was?"

How sweet.  Do you like makeup?

> We could have a discussion about the concepts involved.   As it is, the
> threads devolve into name calling, topic-changing non-sequiturs, and silly
> sound effects.  You seem to start with the assumption that you are right and
> everyone else is wrong, and begin with snark.

I'm still waiting on the binary-digit lexer, Ned.

> There really are people on the list who know a lot about software and
> computer science, including the people you are currently calling
> known-nothings.

I don't know if you are personally qualified for the latter, but agree
somewhat on the part of "software".

> These things are true: There are hex values that represent NaNs.

Why don't you follow your own advice?  Instead of "These things are
true:"  Why don't you say "These things could be true"  OR "*I*
believe that hex values could be used to represent NaN"?

Tell us, which hex value is used to represent NaN?  (thoughts to self:
 all-ones wouldn't make a very good magic number for finding errors,
so I wonder what Ned will dream up....  (btw:  I'm not gay)).   Note
that, just for the record, I was talking strictly about memory (RAM),
not variable assignments.

> Non-Turing-complete languages can be compiled to C.  ASTs don't have enough
> information to compile to machine code.

Please tell us then, what IS enough information to compile to machine
code?   ...rather than just saying that "AST's don't have enough
information to compile to machine code"

>  Data on punched cards can be
> tokenized.  All of these things are true.

*rolls eyes*

> You seem to be a seeker of truth.  Why not listen to others?

Yes, now listening....

-- 
MarkJ
Tacoma, Washington

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

#57571

On 25/10/2013 22:37, Mark Janssen wrote:

>
> I'm still waiting on the binary-digit lexer, Ned.
>

The whole Python world is still waiting on your response to this 
http://code.activestate.com/lists/python-ideas/19908/.  You were asked 
three times originally to respond.  I've referenced this twice yet you 
have conveniently ignored all five requests and will presumably ignore 
this.  What's the problem, cat got your typing fingers?  Or don't you 
have the guts to admit that you were talking bollocks?

-- 
Python is the second best programming language in the world.
But the best has yet to be invented.  Christian Tismer

Mark Lawrence

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

#57588

On Sat, Oct 26, 2013 at 8:37 AM, Mark Janssen <dreamingforward@gmail.com> wrote:
> On Fri, Oct 25, 2013 at 2:07 PM, Ned Batchelder <ned@nedbatchelder.com> wrote:
>> (Offlist)

You responded on-list to a private email that was even tagged as
off-list. Please be more careful and courteous.

Anyway, IEEE floating-point makes it pretty clear that any value that
sets the exponent to all-ones and the mantissa to anything other than
all-zeros is a NaN. So an all-ones hex pattern
(0xFFFFFFFFFFFFFFFF....) will flood the area with NaNs.

You really don't understand IEEE 754 here.

ChrisA

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

#57277

On 2013-10-22, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> On Tue, 22 Oct 2013 14:04:57 +0000, Dave Angel wrote:
>> but here you go on to say the C code is unsafely skipping
>> initialization, which is not the case.
>
> Are you talking generically, or specifically about the C code
> referenced in the link I gave?
>
> "Memory is always zeroed" is one of the advantages of Go over C and C++, 
> at least according to Rob Pike:
>
> http://commandcenter.blogspot.com.au/2012/06/less-is-exponentially-
> more.html

Go initializes variables to defined zero values, not simply to
all-bits zero as (I think) C does.

This isn't as great a feature as it seems, since the zero value
for some built in types, e.g., map, is unusable without manual
construction. In addition, you can't define a zero value for your
own types.

-- 
Neil Cerutti

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

#57300

On 2013-10-22, Neil Cerutti <neilc@norwich.edu> wrote:
> On 2013-10-22, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
>> On Tue, 22 Oct 2013 14:04:57 +0000, Dave Angel wrote:
>>> but here you go on to say the C code is unsafely skipping
>>> initialization, which is not the case.
>>
>> Are you talking generically, or specifically about the C code
>> referenced in the link I gave?
>>
>> "Memory is always zeroed" is one of the advantages of Go over C and C++, 
>> at least according to Rob Pike:
>>
>> http://commandcenter.blogspot.com.au/2012/06/less-is-exponentially-
>> more.html
>
> Go initializes variables to defined zero values, not simply to
> all-bits zero as (I think) C does.

C initializes to defined zero values.  For most machines in use today,
those values _happen_ to be all-bits-zero.

This makes the implementation trivial: chuck them all into some
pre-defined section (e.g. ".bss"), and then on startup, you zero-out
all the bits in the section without having to know what's where within
that section.  If you design a machine such that integer, pointer, and
FP representations where 0, NULL, and 0.0 are all zero-bits, then life
get's tougher for the guys writing the compiler and startup code.

But the language doesn't require or assume that initializer values are
all-bits-zero.  FP values have to be initizliaed to 0.0.  Int's have
to be initialized to integer value 0, pointers have to be initialized
to (void*)0. Nowhere it the languauge is it required or assumed that
any or all of those values are all represented by contiguous blocks of
all-zero-bits.

> This isn't as great a feature as it seems, since the zero value for
> some built in types, e.g., map, is unusable without manual
> construction. In addition, you can't define a zero value for your own
> types.

-- 
Grant Edwards               grant.b.edwards        Yow! Oh my GOD -- the
                                  at               SUN just fell into YANKEE
                              gmail.com            STADIUM!!

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

#57311

On 2013-10-22, Grant Edwards <invalid@invalid.invalid> wrote:

> C initializes to defined zero values.  For most machines in use today,
> those values _happen_ to be all-bits-zero.
>
> This makes the implementation trivial: chuck them all into some
> pre-defined section (e.g. ".bss"), and then on startup, you zero-out
> all the bits in the section without having to know what's where within
> that section.  If you design a machine such that integer, pointer, and
> FP representations where 0, NULL, and 0.0 are all zero-bits, then life
                                               ^
                                              not
                                              
> get's tougher for the guys writing the compiler and startup code.

-- 
Grant Edwards               grant.b.edwards        Yow! We are now enjoying
                                  at               total mutual interaction in
                              gmail.com            an imaginary hot tub ...

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

#57265

On 2013-10-22, Dave Angel <davea@davea.name> wrote:
> On 22/10/2013 08:00, Steven D'Aprano wrote:

>>     [quote]
>>     C does not require you to set static global arrays to ?0?, so the 
>>     for loop in the main function can go...
>>
>> Wait a minute... Haskell, I'm pretty sure, zeroes memory. C doesn't. So 
>
> Static int variables are in fact zeroed.  However, most C compilers
> do it by putting four bytes (or whatever) into the image of the
> executable so it has no runtime cost.

No, that's not how gcc works (nor is it how any other C compiler I've
ever seen works).  Static variables get located in a "bss" section[1],
which is zeroed out at run-time by startup code that gets executed
before main() is called.  The ELF executable contains headers that
describe the size/location of bss section, but the object file
contains no actual _data_. 

[1] IIRC, the name "bss" is a historical hold-over from the PDP-11
    assembler directive that is used to declare a section of memory
    that is to be filled with zeros.  Not all compilers use that
    section name, but they all use the same mechanism.

> int  myvar = 34 * 768;
>
> it'll put the product directly in the executable image, and no
> runtime code is generated.

That is true.

-- 
Grant Edwards               grant.b.edwards        Yow! My EARS are GONE!!
                                  at               
                              gmail.com            

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

#57261

On 22 October 2013 13:00, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Tue, 22 Oct 2013 10:14:16 +0100, Oscar Benjamin wrote:
>
>> On 22 October 2013 00:41, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
>>>
>>> Are you suggesting that gcc is not a decent compiler?
>>
>> No.
>>
>>> If "optimize away
>>> to the null program" is such an obvious thing to do, why doesn't the
>>> most popular C compiler in the [FOSS] world do it?
>>
>> It does if you pass the appropriate optimisation setting (as shown in
>> haypo's comment). I should have been clearer.
>
> "C can do nothing 10 times faster than Python!" -- well, okay, but what
> does that tell you about my long-running web server app? Benchmarks at
> the best of time are only suggestive, benchmarks for null programs are
> even less useful.

This is precisely my point. They should show a benchmark that is not
semantically equivalent to the null program. I modified their example
to do that so that it wasn't simply a case of removing dead code and
then found that the C version performed 6-7 times faster than the PyPy
version. Had they simply stated that I would have been impressed.

At the bottom of this post I show a much better benchmark that shows
how PyPy can come very close to C performance for intensive floating
point computation. Note that although it is simple the benchmark
actually produces a result and none of the computation can be skipped
as dead code (why would I put that in?). Also note that both the C
binary and the script produce exactly the same numeric output. It's
also a simple example of numerical integration - something that is
often a bottleneck in scientific computation.

For the benchmark I find that the gcc -O3 binary runs in 4.6s and PyPy
runs the script in 6.9s (CPython 2.7 takes 600 seconds). That is
impressive and makes me think that there may be no need for me to use
C for things like that. To be sure I'd have to scale it up a bit to
see what happens when I break it apart into many functions and use
lists in PyPy vs arrays in C.

> [...]
>> They are more than carefully crafted. They are useless and misleading.
>> It's reasonable to contrive of a simple CPU-intensive programming
>> problem for benchmarking. But the program should do *something* even if
>> it is contrived. Both programs here consist *entirely* of dead code.
>
> But since the dead code is *not* eliminated, it is actually executed. If
> it's executed, it's not really dead, is it? Does it really matter that
> you don't do anything with the result? I'm with Maciej on this one --
> *executing* the code given is faster in PyPy than in C, at least for this
> C compiler. Maybe C is faster to not execute it. Is that really an
> interesting benchmark? "C does nothing ten times faster than PyPy does
> something!"

I don't think it is reasonable to compare those things and I was
joking when I said that the optimised C version was 600 times faster
because this is an absurd benchmark - see the much better one below.

> Given a sufficiently advanced static analyser, PyPy could probably
> special-case programs that do nothing. Then you're in a race to compare
> the speed at which the PyPy runtime environment can start up and do
> nothing, versus a stand-alone executable that has to start up and do
> nothing. If this is a benchmark that people care about, I suggest they
> need to get out more :-)

Like Chris I have also had situations where startup time mattered and
it can vary substantially between different interpreters and binaries.
I have GNU Octave on Windows and it literally takes 20 seconds to
start up. Matlab is worse: it takes about 1 minute so I don't tend to
use it for CLI scripts much.


Oscar


The benchmark:

$ cat euler.py
#!/usr/bin/env pypy

import math

def main():
    x = 1
    v = 0
    t = 0
    T = 1
    dt = 2**-30
    while t < T:
        dxdt = v
        dvdt = - x
        x += dt * dxdt
        v += dt * dvdt
        t += dt
    print('t = %.2e' % t)
    print('x = %.2e' % x)
    print('v = %.2e' % v)
    print('x_err = %.e' % (x - math.cos(t)))
    print('x_err = %.2e' % (v + math.sin(t)))

main()
$ time pypy euler.py
t = 1.00e+00
x = 5.40e-01
v = -8.41e-01
x_err = 3e-10
x_err = -3.92e-10

real    0m6.907s
user    0m0.076s
sys     0m0.045s
$ cat euler.c
#include <stdio.h>
#include <math.h>

int main()
{
    double x = 1;
    double v = 0;
    double t = 0;
    double T = 1;
    double dt = pow(2, -30);
    double dxdt, dvdt;
    while (t < T)
    {
        dxdt = v;
        dvdt = - x;
        x += dt * dxdt;
        v += dt * dvdt;
        t += dt;
    }
    printf("t = %.2e\n", t);
    printf("x = %.2e\n", x);
    printf("v = %.2e\n", v);
    printf("x_err = %.e\n", x - cos(t));
    printf("x_err = %.2e\n", v + sin(t));

    return 0;
}
$ gcc -O3 euler.c
$ time ./a.exe
t = 1.00e+000
x = 5.40e-001
v = -8.41e-001
x_err = 3e-010
x_err = -3.92e-010

real    0m4.609s
user    0m0.015s
sys     0m0.000s

$ time python euler.py  # CPython 2.7
t = 1.00e+00
x = 5.40e-01
v = -8.41e-01
x_err = 3e-10
x_err = -3.92e-10

real    9m51.818s
user    0m0.015s
sys     0m0.015s

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

#57202

On Mon, Oct 21, 2013 at 12:46 AM, Steven D'Aprano <steve@pearwood.info> wrote:
> On Sun, 20 Oct 2013 20:35:03 -0700, Mark Janssen wrote:
>
> [Attribution to the original post has been lost]
>>> Is a jit implementation of a language (not just python) better than
>>> traditional ahead of time compilation.
>>
>> Not at all.  The value of jit compilation, I believe, is purely for the
>> dynamic functionality that it allows.  AOT compilation will never allow
>> that, but in return you get massive performance and runtime-size gains
>
> On the contrary, you have that backwards. An optimizing JIT compiler can
> often produce much more efficient, heavily optimized code than a static
> AOT compiler,

This is horseshit.

> and at the very least they can optimize different things
> than a static compiler can.

Okay sure.  But now you've watered down your claim that's it's not
saying much of anything.

> This is why very few people think that, in
> the long run, Nuitka can be as fast as PyPy, and why PyPy's ultimate aim
> to be "faster than C" is not moonbeams:

It is moonbeams, but that's a good thing.  I think you don't
understand how computers work, Steven.
In any event, PyPy is a great project for those who want experiment
with compiler and language design.

> JIT compilation is really about optimization,

No.

> which is why languages like
> Java and .NET which could easily be compiled to machine code at compile
> time generally use an intermediate bytecode and a JIT compiler instead.
> They're not doing it for dynamism since they aren't dynamic languages.
> It's a way of generating more aggressive (i.e. better but harder)
> optimizations based on information only available at runtime.

This must is true, but not for reasons you understand.

-- 
MarkJ
Tacoma, Washington

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

#57205

On 10/21/13 4:14 PM, Mark Janssen wrote:
> On Mon, Oct 21, 2013 at 12:46 AM, Steven D'Aprano <steve@pearwood.info> wrote:
>> On Sun, 20 Oct 2013 20:35:03 -0700, Mark Janssen wrote:
>>
>> [Attribution to the original post has been lost]
>>>> Is a jit implementation of a language (not just python) better than
>>>> traditional ahead of time compilation.
>>> Not at all.  The value of jit compilation, I believe, is purely for the
>>> dynamic functionality that it allows.  AOT compilation will never allow
>>> that, but in return you get massive performance and runtime-size gains
>> On the contrary, you have that backwards. An optimizing JIT compiler can
>> often produce much more efficient, heavily optimized code than a static
>> AOT compiler,
> This is horseshit.

Surely we can discuss this without resorting to swearing.
>> and at the very least they can optimize different things
>> than a static compiler can.
> Okay sure.  But now you've watered down your claim that's it's not
> saying much of anything.
>
>> This is why very few people think that, in
>> the long run, Nuitka can be as fast as PyPy, and why PyPy's ultimate aim
>> to be "faster than C" is not moonbeams:
> It is moonbeams, but that's a good thing.  I think you don't
> understand how computers work, Steven.
I think Steven has earned the benefit of the doubt when it comes to 
understanding computer.  Did you read the links he provided? Do you 
believe that author also doesn't understand how computers work?

Mark, disagreement doesn't have to lead to ad-hominem attacks.  If you 
think Steven is wrong about what JIT compilers can do, please explain.  
Simply calling his statements horseshit and saying he doesn't understand 
computers is not a rebuttal.

> In any event, PyPy is a great project for those who want experiment
> with compiler and language design.
>
>> JIT compilation is really about optimization,
> No.

Please tell us what JIT compilation is about.
>
>> which is why languages like
>> Java and .NET which could easily be compiled to machine code at compile
>> time generally use an intermediate bytecode and a JIT compiler instead.
>> They're not doing it for dynamism since they aren't dynamic languages.
>> It's a way of generating more aggressive (i.e. better but harder)
>> optimizations based on information only available at runtime.
> This must is true, but not for reasons you understand.
>
Again, a statement with no supporting information.

*sigh*

If someone says something that seems wrong to you, there are a number of 
possibilities: 1) you are wrong, 2) they are wrong, or 3) you haven't 
understood each other yet.  Please have the humility to at least 
consider option 3 first.

--Ned.

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

#57229

On Tuesday, October 22, 2013 1:59:36 AM UTC+5:30, Ned Batchelder wrote:
> On 10/21/13 4:14 PM, Mark Janssen wrote:
> 
> > On Mon, Oct 21, 2013 at 12:46 AM, Steven D'Aprano wrote:
> >> An optimizing JIT compiler can
> >> often produce much more efficient, heavily optimized code than a static
> >> AOT compiler,
> > This is horseshit.
> 
> Surely we can discuss this without resorting to swearing.

Thanks Ned for the intervention.
It is good to have 'interesting' and even 'hot' discussions.
Beyond a point they remain hot but not interesting

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

#57191

Hey all,

Thanks, i've been working on this basically on my own 95% of the compiler is all my code, in my spare time. Its been fairly scary all of this for me. I personally find this as a real source of interest to really demystify compilers and really what Jit compilation really is under the hood.

For example if your really interested to see what jit compilation really is (not magic) look at:
http://compilers.iecc.com/comparch/article/10-03-063

And i really believe in this project. Though i really want to say away from comparing my project to any others out there. As they are much more mature than mine.

For example its only a few commits back your successfully able to compile:

import sys

So i think its fairly unfair comparisons could get me into trouble. Whats taken so long is i do not reuse the python runtime like the others. Other projects do this to maintain computability mostly. But i wanted to test doing this entirely from scratch partly for my own interest and that the python runtime was designed for an interpreter, not compilers at least ahead of time.

Its interesting a few things come up what about:

exec and eval. I didn't really have a good answer for this at my talk at PYCon IE 2013 but i am going to say no. I am not going to implement these. Partly because eval and exec at least to me are mostly from developing interpreters as a debugging exercise so the test doesn't have to invoke the program properly and feed in strings to interpret at least thats what i have done in the past with an virtual machine i wrote before gccpy.

I think anything you look up on eval and exec you shouldn't use them in production code as it could lead to a lot of issues. I can see their use in quick dirty uses but i don't think they really are part of the python language in my opinion its just some builtin functions that you can invoke. Another issue i had was:

class myClass: pass

I currently don't allow this but i've re thought this and i am going to try and implement this properly before i had a really complicated to pass to quess the type of a struct but i realise currently with how things work this may not be the case.

As a personal comment i think this is kind of funny as why not use a dict. But i can see the use for it now, and i want to implement it.

What i will say is gccpy is moving along with each milestone i will achieve over the course of the first half of 2014 i reckon i could at least compile half of a decnt python test suite. Its taken me so long to get used to the GCC code base and how i want to implement things i've re-wrote the runtime and the compiler probably at least 4 times and i am going to rewrite part of the runtime today for the next week or so. I think tis a worth while project.

I don't think this will ever be on par with PyPy or CPython as professional as those projects are i really respect their work i mean i look up to them (loads) i am just a guy who likes compilers and it isnt my day job i don't get paid for this i just enjoy the challenge and i hope you understand that this is my baby and i am very protective of my project :).

I hope in a few months when i start compiling testsuiites i will publish benchmarks what i will say is it looks pretty good right now only 1 case so far (that i have tested) where i am not faster than CPython and its only because i havent been compiling the runtime library with correct CFLAGS like -O2 etc i wasnt passing anything another is i have tonnnes of debugging malloc all over the show slowing it down because i need to rewrite part of the runtime so yeah. I've been fighting GCC for 4 years now i am fighting my own code ;).

Final note i am not saying JIT is bad or not the way to do things i personally think this question isn't answered and i can see the case for it there are down sides that jit people wont talk about.

The complexity of maintaining a j it in project is probably the main one and optimisations at runtime make it even more mental as they are hard to do is an under statement never mind they aren't as common as you would want to believe outside of target specifics which gcc already knows (-mtune*). I do believe JIT is the way forward but i think something in languages needs to really be designed from that perspective and maybe even cpu's to help with some kind of instructions to help maintain a destination between runtime and user code or something (making tail call optimisations easier on dynamic languages) maybe?

Thanks.

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

#57203

On Mon, Oct 21, 2013 at 4:08 AM, Philip Herron
<herron.philip@googlemail.com> wrote:
> Thanks, i've been working on this basically on my own 95% of the compiler is all my code, in my spare time. Its been fairly scary all of this for me. I personally find this as a real source of interest to really demystify compilers and really what Jit compilation really is under the hood.

So I'm curious, not having looked at your code, are you just
translating python code into C code to make your front-end to gcc?
Like converting "[1,2,3]" into a C linked-list data structure and
making 1 an int (or BigNum?)?

-- 
MarkJ
Tacoma, Washington

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

#57207

On Monday, 21 October 2013 21:26:06 UTC+1, zipher  wrote:
> On Mon, Oct 21, 2013 at 4:08 AM, Philip Herron
> 
> <herron.philip@googlemail.com> wrote:
> 
> > Thanks, i've been working on this basically on my own 95% of the compiler is all my code, in my spare time. Its been fairly scary all of this for me. I personally find this as a real source of interest to really demystify compilers and really what Jit compilation really is under the hood.
> 
> 
> 
> So I'm curious, not having looked at your code, are you just
> 
> translating python code into C code to make your front-end to gcc?
> 
> Like converting "[1,2,3]" into a C linked-list data structure and
> 
> making 1 an int (or BigNum?)?
> 
> 
> 
> -- 
> 
> MarkJ
> 
> Tacoma, Washington

No its not like those 'compilers' i dont really agree with a compiler generating C/C++ and saying its producing native code. I dont really believe its truely within the statement. Compilers that do that tend to put in alot of type saftey code and debugging internals at a high level to get things working in other projects i am not saying python compilers here i havent analysed enough to say this.

What i mean as a front-end is jut like GCC G++ gccgo gfortran it all works the same each of these are front-ends you can pass all those mental gcc options like -O3 -mtune -fblabla. it is implemented as part of gcc and you can 'bootstrap python'. You can -fdump-tree-all etc.

What i can say is jit compilation is really mistified' in a big way when it comes to projects like pypy when its implemented in python how can it call mmap to make an executable memory block etc. When it comes to compilation i think it gets fairly mistified in the python compiler community even more.

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

#57215

> No its not like those 'compilers' i dont really agree with a compiler generating C/C++ and saying its producing native code. I dont really believe its truely within the statement. Compilers that do that tend to put in alot of type saftey code and debugging internals at a high level to get things working in other projects i am not saying python compilers here i havent analysed enough to say this.

Hmm, well what I'd personally find interesting from a computer science
point of view is a app that will take a language specification in BNF
(complete with keywords and all) and output C code which is then
compiled to an executable as normal.  This is how a front-end should
be designed.  A middle-layer for translating common language elements
like lists, sets, etc, could make it easy.

-- 
MarkJ
Tacoma, Washington

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

#57230

Mark Janssen <dreamingforward@gmail.com> writes:

>> No its not like those 'compilers' i dont really agree with a compiler generating C/C++ and saying its producing native code. I dont really believe its truely within the statement. Compilers that do that tend to put in alot of type saftey code and debugging internals at a high level to get things working in other projects i am not saying python compilers here i havent analysed enough to say this.
>
> Hmm, well what I'd personally find interesting from a computer science
> point of view is a app that will take a language specification in BNF
> (complete with keywords and all) and output C code which is then
> compiled to an executable as normal.  This is how a front-end should
> be designed.  A middle-layer for translating common language elements
> like lists, sets, etc, could make it easy.

A language specification in BNF is just syntax. It doesn't say anything
about semantics. So how could this be used to produce executable C code
for a program? BNF is used to produce parsers. But a parser isn't
sufficient.
-- 
Piet van Oostrum <piet@vanoostrum.org>
WWW: http://pietvanoostrum.com/
PGP key: [8DAE142BE17999C4]

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

#57233

> A language specification in BNF is just syntax. It doesn't say anything
> about semantics. So how could this be used to produce executable C code
> for a program? BNF is used to produce parsers. But a parser isn't
> sufficient.

A C program is just syntax also.  How does the compiler generate
executable machine code?  Extrapolate into a Python front-end to C.

-- 
MarkJ
Tacoma, Washington

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

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

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

csiph-web