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

Groups > comp.lang.forth > #18286 > unrolled thread

Opinions on googl's go language?

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

Contents

  Opinions on googl's go language? the_gavino_himself <visphatesjava@gmail.com> - 2012-12-26 02:13 -0800
    Re: Opinions on googl's go language? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-12-27 16:53 -0800
      Re: Opinions on googl's go language? The Beez <the.beez.speaks@gmail.com> - 2012-12-28 02:49 -0800
        Re: Opinions on googl's go language? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-12-28 07:59 -0600
          Re: Opinions on googl's go language? "A. K." <akk@nospam.org> - 2012-12-28 16:26 +0100
            Re: Opinions on googl's go language? Richard Owlett <rowlett@pcnetinc.com> - 2012-12-28 11:21 -0600
              Re: Opinions on googl's go language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-12-28 17:23 +0000
                Re: Opinions on googl's go language? Richard Owlett <rowlett@pcnetinc.com> - 2012-12-28 16:20 -0600
                  Re: Opinions on googl's go language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-08 17:55 +0000
                Re: Opinions on googl's go language? mhx@iae.nl (Marcel Hendrix) - 2012-12-28 23:48 +0200
                Re: Opinions on googl's go language? Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-28 23:56 +0100
                  Re: Opinions on googl's go language? gavino_himself <visploveslisp@gmail.com> - 2013-01-06 03:53 -0800
                  Re: Opinions on googl's go language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-08 16:22 +0000
                    Re: Opinions on googl's go language? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-08 12:34 -0600
                      Re: Opinions on googl's go language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-23 16:40 +0000
                        Re: Opinions on googl's go language? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-23 11:36 -0600
                          Re: Opinions on googl's go language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-24 12:46 +0000
                            Re: Opinions on googl's go language? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-24 09:17 -0600
                              Re: Opinions on googl's go language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-24 17:23 +0000
                                Re: Opinions on googl's go language? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-24 13:16 -0600
                                  Re: Opinions on googl's go language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-05 17:59 +0000
                                    Re: Opinions on googl's go language? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-05 12:38 -0600
              Re: Opinions on googl's go language? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-12-30 03:24 -0600
                Re: Opinions on googl's go language? Richard Owlett <rowlett@pcnetinc.com> - 2012-12-30 12:14 -0600
                  Re: Opinions on googl's go language? Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-30 22:17 +0100
            Re: Opinions on googl's go language? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-12-30 03:22 -0600
              Re: Opinions on googl's go language? Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-30 14:25 +0100
          Re: Opinions on googl's go language? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-12-28 20:55 -0800
            Re: Opinions on googl's go language? The Beez <the.beez.speaks@gmail.com> - 2012-12-29 03:35 -0800
              Re: Opinions on googl's go language? Doug Hoffman <glidedog@gmail.com> - 2012-12-29 11:49 -0500
                Re: Opinions on googl's go language? The Beez <the.beez.speaks@gmail.com> - 2012-12-30 01:57 -0800
                  Re: Opinions on googl's go language? Doug Hoffman <glidedog@gmail.com> - 2012-12-30 07:01 -0500
                    Re: Opinions on googl's go language? The Beez <the.beez.speaks@gmail.com> - 2012-12-31 00:29 -0800
                  Re: Opinions on googl's go language? Doug Hoffman <glidedog@gmail.com> - 2013-01-02 09:18 -0500
                    Re: Opinions on googl's go language? Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-02 20:32 -0800
                      Re: Opinions on googl's go language? Doug Hoffman <glidedog@gmail.com> - 2013-01-03 06:56 -0500
                    Re: Opinions on googl's go language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-08 15:50 +0000
                      Re: Opinions on googl's go language? Doug Hoffman <glidedog@gmail.com> - 2013-01-08 21:41 -0500
                        Re: Opinions on googl's go language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-23 16:55 +0000
                          Re: Opinions on googl's go language? Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-23 20:23 +0100
                          Re: Opinions on googl's go language? Doug Hoffman <glidedog@gmail.com> - 2013-01-24 09:46 -0500
            Re: Opinions on googl's go language? Alex McDonald <blog@rivadpm.com> - 2012-12-29 07:41 -0800
        Re: Opinions on googl's go language? gavino_himself <visploveslisp@gmail.com> - 2012-12-29 19:29 -0800
    Re: Opinions on googl's go language? tcholoka@gmail.com - 2013-01-03 09:36 -0800
      Re: Opinions on googl's go language? Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-06 00:32 -0800
        Re: Opinions on googl's go language? Mark Wills <forthfreak@gmail.com> - 2013-01-06 01:26 -0800
        Re: Opinions on googl's go language? gavino_himself <visploveslisp@gmail.com> - 2013-01-06 03:57 -0800
        Re: Opinions on googl's go language? tcholoka@gmail.com - 2013-01-06 06:02 -0800
          Re: Opinions on googl's go language? Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-07 23:41 -0800
            Re: Opinions on googl's go language? tcholoka@gmail.com - 2013-01-08 00:15 -0800
      Re: Opinions on googl's go language? gavino_himself <visploveslisp@gmail.com> - 2013-01-06 03:56 -0800

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

#18286 — Opinions on googl's go language?

http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/Go-In-Three-Easy-Pieces

Go is a statically typed, compiled language with a dynamic and lightweight feel. With Go you get the efficiency benefits of being close to the machine–your programs compile to native code–with the productivity benefits of a scripting language. Go apps tend to run faster and use less memory than equivalent Python or Java apps, and Go's concurrency primitives make it easy to write web applications. 


sounds like forth a bit!!

They seem to have stolen the compile as you go idea?
Not sure
They have definitly attaced the 16 cpu in 1 box problem, and web!!
wow

[toc] | [next] | [standalone]

#18310

On Dec 26, 3:13 am, the_gavino_himself <visphatesj...@gmail.com>
wrote:
> http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/Go-In-Three-...
>
> Go is a statically typed, compiled language with a dynamic and lightweight feel. With Go you get the efficiency benefits of being close to the machine–your programs compile to native code–with the productivity benefits of a scripting language. Go apps tend to run faster and use less memory than equivalent Python or Java apps, and Go's concurrency primitives make it easy to write web applications.
>
> sounds like forth a bit!!
>
> They seem to have stolen the compile as you go idea?
> Not sure
> They have definitly attaced the 16 cpu in 1 box problem, and web!!
> wow

This isn't the 1980s anymore, when the only languages available were
C, Pascal and Forth, and none of them were any good, so all
professional work was done in Z80 assembly language. Nowadays we have
dozens of languages available that are quite powerful. This is true
for desktop-computer programming anyway --- on micro-controllers the
only choice is C, although there are a few others such as Spin, and
none of them work as well as good old assembly-language.

Gavino, you should just figure out what you want to do, find an
appropriate language, and learn it. If Go looks like it is appropriate
for what you want to do, then learn that one. I don't think that Forth
is a good choice for desktop-computer programming, which is obviously
what you are interested in, so try Go or one of the others instead.

I think Go is interesting too. I'm already not-learning Scheme though,
so there is no point in not-learning Go at the same time. I'm sitting
at the bookstore right now looking at a book, "Build Awesome Command-
Line Applications in Ruby." Maybe I could not-learn Ruby too! My point
is that none of these languages magically produce programs, but all of
them require the programmer to invest some time and effort in learning
them, at which time they produce programs, but still not magically, as
work is required.

BTW --- Cat looks like another cool language. I installed that on my
computer and I'm not-learning it too now. If I do learn it though, I
will likely be the only person in the world who uses it. :-)

P.S. for Gavino --- The guaranteed way to fail at learning a
programming language is to invest a lot of time in learning it. I
mean, reading books gets boring quickly, and you don't really learn
anything from the books because you don't have any context to put your
knowledge in, and so you immediately forget everything that you've
learned. The best way to learn a programming language is to dive right
into writing a program in that language. Use the books as a reference
while doing this, but don't just sit and read the book like a novel.
Your first effort will be horribly low quality, but if you can get the
program to work (even grossly inefficiently, if you are not using the
available libraries and/or not using the language the way that it was
designed to be used), you will have learned quite a lot about the
language. Your next program will be better. Repeat indefinitely.

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

#18314

On Dec 28, 1:53 am, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
> P.S. for Gavino --- The guaranteed way to fail at learning a
> programming language is to invest a lot of time in learning it. I
> mean, reading books gets boring quickly, and you don't really learn
> anything from the books because you don't have any context to put your
> knowledge in, and so you immediately forget everything that you've
> learned. The best way to learn a programming language is to dive right
> into writing a program in that language. Use the books as a reference
> while doing this, but don't just sit and read the book like a novel.
> Your first effort will be horribly low quality, but if you can get the
> program to work (even grossly inefficiently, if you are not using the
> available libraries and/or not using the language the way that it was
> designed to be used), you will have learned quite a lot about the
> language. Your next program will be better. Repeat indefinitely.

Very true. I learned that in 1986 (about, for arguments sake) when I
spent weeks reading a host of C manuals and ended up with a 12 hour
session making a page-long C program. BTW, one of the best books on C
is "Advanced C" by the Andersons and the always helpful -S option of
the C compiler.

BTW, I learned Forth by decompiling the whole darn thing (to Z80
assembly) and the Appendix of "Advanced Abersoft Forth". Books were of
very little use.

Hans Bezemer

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

#18315

The Beez <the.beez.speaks@gmail.com> wrote:

> I learned that in 1986 (about, for arguments sake) when I spent
> weeks reading a host of C manuals and ended up with a 12 hour
> session making a page-long C program. BTW, one of the best books on
> C is "Advanced C" by the Andersons and the always helpful -S option
> of the C compiler.
> 
> BTW, I learned Forth by decompiling the whole darn thing (to Z80
> assembly) and the Appendix of "Advanced Abersoft Forth". Books were
> of very little use.

I think that if you know machine language you have a huge advantage
over those who don't.  All programming languages, no matter how
complex, are ultimately reducible to those machine instructions.
Knowledge of them gives you a key that helps you to understand
everything that a computer does.

Of course, knowledge of machine language isn't sufficient to
understand everything, but it's a huge help.  Many students aren't
taught such things today and they're at a huge disadvantage when
compared with my generation.

Andrew.

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

#18316

On 28.12.2012 14:59, Andrew Haley wrote:
> The Beez <the.beez.speaks@gmail.com> wrote:
>
>> I learned that in 1986 (about, for arguments sake) when I spent
>> weeks reading a host of C manuals and ended up with a 12 hour
>> session making a page-long C program. BTW, one of the best books on
>> C is "Advanced C" by the Andersons and the always helpful -S option
>> of the C compiler.
>>
>> BTW, I learned Forth by decompiling the whole darn thing (to Z80
>> assembly) and the Appendix of "Advanced Abersoft Forth". Books were
>> of very little use.
>
> I think that if you know machine language you have a huge advantage
> over those who don't.  All programming languages, no matter how
> complex, are ultimately reducible to those machine instructions.
> Knowledge of them gives you a key that helps you to understand
> everything that a computer does.
>
> Of course, knowledge of machine language isn't sufficient to
> understand everything, but it's a huge help.  Many students aren't
> taught such things today and they're at a huge disadvantage when
> compared with my generation.
>
> Andrew.
>

Really? It seems that it has become cheaper to throw more hardware into 
systems than optimizing and tuning software. Eg Samsung's S4 smartphone 
S4 is driven by a quad core CPU (just a few years ago that was the 
ultimate high performance server CPU). But does it help students to 
understand the system by memorizing its machine instructions?

In my younger days I used to be good at soldering resistors and 
transistors to build electronic circuits. When I disassemble a mobile 
phone today I can only guess what is what, let alone soldering around in 
it...

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

#18317

A. K. wrote:
> On 28.12.2012 14:59, Andrew Haley wrote:
>> The Beez <the.beez.speaks@gmail.com> wrote:
>>
>>> I learned that in 1986 (about, for arguments sake) when I
>>> spent
>>> weeks reading a host of C manuals and ended up with a 12
>>> hour
>>> session making a page-long C program. BTW, one of the
>>> best books on
>>> C is "Advanced C" by the Andersons and the always helpful
>>> -S option
>>> of the C compiler.
>>>
>>> BTW, I learned Forth by decompiling the whole darn thing
>>> (to Z80
>>> assembly) and the Appendix of "Advanced Abersoft Forth".
>>> Books were
>>> of very little use.
>>
>> I think that if you know machine language you have a huge
>> advantage
>> over those who don't.  All programming languages, no
>> matter how
>> complex, are ultimately reducible to those machine
>> instructions.
>> Knowledge of them gives you a key that helps you to
>> understand
>> everything that a computer does.
>>
>> Of course, knowledge of machine language isn't sufficient to
>> understand everything, but it's a huge help.  Many
>> students aren't
>> taught such things today and they're at a huge
>> disadvantage when
>> compared with my generation.
>>
>> Andrew.
>>
>
> Really? It seems that it has become cheaper to throw more
> hardware into systems than optimizing and tuning software.
> Eg Samsung's S4 smartphone S4 is driven by a quad core CPU
> (just a few years ago that was the ultimate high performance
> server CPU). But does it help students to understand the
> system by memorizing its machine instructions?


Donald E. Knuth apparently thought the concept important 
enough to create MIX.
  [ _The Art of Computer Programming_ , Vol 1 - Fundamental 
Algorithms, 2nd Edition , c1973, p xi]

Reading Andrew's post got me thinking. As both a teaching 
tool and attention grabber might an appropriately visual 
Turing Machine simulator be useful as a primary/secondary 
school tool?



>
> In my younger days I used to be good at soldering resistors
> and transistors to build electronic circuits. When I
> disassemble a mobile phone today I can only guess what is
> what, let alone soldering around in it...
>

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

#18318

Richard Owlett <rowlett@pcnetinc.com> writes:
>A. K. wrote:
>> But does it help students to understand the
>> system by memorizing its machine instructions?

In itself, no.  But there's more to learning machine-level programming
than learning the machine instructions.  You learn about memory and
addresses, bits, bytes, words, and how they are related to data.  It
is necessary to learn some assembly language to make all this concrete.

Forth might be a viable replacement for assembly language, as it also
exposes these low-level concepts, but assembly/machine language has
the advantage that everything is based on it.

>Donald E. Knuth apparently thought the concept important 
>enough to create MIX.
>  [ _The Art of Computer Programming_ , Vol 1 - Fundamental 
>Algorithms, 2nd Edition , c1973, p xi]

One might say that this was long ago, but more recently he created
MMIX for reworking TAoCP.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2012: http://www.euroforth.org/ef12/

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

#18320

Anton Ertl wrote:
> Richard Owlett <rowlett@pcnetinc.com> writes:
>> A. K. wrote:
>>> But does it help students to understand the
>>> system by memorizing its machine instructions?
>
> In itself, no.  But there's more to learning machine-level programming
> than learning the machine instructions.  You learn about memory and
> addresses, bits, bytes, words, and how they are related to data.  It
> is necessary to learn some assembly language to make all this concrete.
>
> Forth might be a viable replacement for assembly language, as it also
> exposes these low-level concepts, but assembly/machine language has
> the advantage that everything is based on it.
>
>> Donald E. Knuth apparently thought the concept important
>> enough to create MIX.
>>   [ _The Art of Computer Programming_ , Vol 1 - Fundamental
>> Algorithms, 2nd Edition , c1973, p xi]
>
> One might say that this was long ago, but more recently he created
> MMIX for reworking TAoCP.
>
> - anton
>


You snipped TOO much and failed to highlight snippage :<
Do you agree with me or no? ?? ??? ????? :<

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

#18574

Richard Owlett <rowlett@pcnetinc.com> writes:
>Anton Ertl wrote:
>> Richard Owlett <rowlett@pcnetinc.com> writes:
>>> A. K. wrote:
>>>> But does it help students to understand the
>>>> system by memorizing its machine instructions?
>>
>> In itself, no.  But there's more to learning machine-level programming
>> than learning the machine instructions.  You learn about memory and
>> addresses, bits, bytes, words, and how they are related to data.  It
>> is necessary to learn some assembly language to make all this concrete.
>>
>> Forth might be a viable replacement for assembly language, as it also
>> exposes these low-level concepts, but assembly/machine language has
>> the advantage that everything is based on it.
>>
>>> Donald E. Knuth apparently thought the concept important
>>> enough to create MIX.
>>>   [ _The Art of Computer Programming_ , Vol 1 - Fundamental
>>> Algorithms, 2nd Edition , c1973, p xi]
>>
>> One might say that this was long ago, but more recently he created
>> MMIX for reworking TAoCP.
>>
>> - anton
>>
>
>
>You snipped TOO much and failed to highlight snippage :<

I followed standard Usenet practice in citing only what I comment on.
Highlighting snippage is done only when text is snipped inside a cited
block, not at the fringes.  Looking at your posting
<HpmdnZRVcK-1SEDNnZ2dnUVZ_vWdnZ2d@supernews.com>, it seems to me that
you snipped too little.

>Do you agree with me or no? ?? ??? ????? :<

Does it matter?  And does it not follow from what I wrote?  I
supported your argument by citing more recent work, so yes, I agree
with that part.

Concerning the Turing machine, that's something for theoretcial
computer scientists; teaching that may or may not be appropriate for
the schools you had in mind, but I don't think it will teach the
children anything about the architecture of real computers.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2012: http://www.euroforth.org/ef12/

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

#18324

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes Re: Opinions on googl's go language?
[..]
>>Donald E. Knuth apparently thought the concept important 
>>enough to create MIX.
>>  [ _The Art of Computer Programming_ , Vol 1 - Fundamental 
>>Algorithms, 2nd Edition , c1973, p xi]
>
>One might say that this was long ago, but more recently he created
>MMIX for reworking TAoCP.

Around 1994 I wrote an assembler/disassembler/emulator for MIX.

Checking it just now, I found two bugs. The program used iForth's
VSAVE/VRESTORE feature to scroll the screen. Unfortunately, CELLS 
was coded where "4" was really appropriate. Another 64-bit error 
was the conversion of MIX's 30 bits to bytes. That used host CPU 
roll's which are 64 bits by now.

-marcel

-- Easter Source --------------------------------------------------------

(* ************************************************************ *
 *								*	
 *	      	    Find the date of EASTER			*
 *								*
 *	Knuth, Fundamental Algorithms, Exercise 1.3.2.14 	*
 *								*
 * ************************************************************ *)

\ View the output written to  ans  with "ans TO dumploc  start GO".

		MIXAL

		FWD 	eastx
		FWD	Y
		FWD	G
		FWD	N
		FWD	Xplus12
		FWD	Dplus3
		
		ORIG 	1000

| march		ALF MARCH
| april		ALF APRIL
| ans		ALF      
| day		ALF DD   		\ Note the invisible 3 spaces here!
| month		ALF MMMMM
		ALF      		\ Note the invisible 3 spaces here!
| year		ALF YYYYY
		ORIG	* 20 +
| C		CON	0		\ C times byte size

| easter	STJ	eastx
		STX	Y
| G		ENTA	0		\ _E1._
		DIV	=19=
		INCX	1
		STX	G(0:2)
		LDA	Y		\ _E2._
		MUL	=1 100 // 1+=	\ see
		INCA	1		\  below
		STA	C(1:4)
		MUL	=3 4 // 1+=	\ _E3._	
		STA	Xplus12(0:2)
					\ MIXAL:  LDA =8(1:1)=
		LDA	=8 /bits 4 ** LSHIFT=
		MUL	C		\ rA=8C
		INCA	680		\ 680=5+27*25
		MUL	=1 25 // 1+=	\ rA=Z+32
| Xplus12	DECA	0
		STA	1F(0:2)		\ Z+20-X
		LDA	Y		\ _E4._
		MUL	=1 4 // 1+=
		ADD	Y
		SUB	Xplus12(0:2)
		INCA	5
		STA	Dplus3
		ENTA	0		\ _E5._
		MUL	=11=
| 1H		INCX	0
		DIV	=30=
		JXNN	* 2+		\ See exercise 15
		INCX	30
		CMPX	=24=
		JE	1F
		CMPX	=25=
		JNE	2F
		LDA	G(0:2)
		DECA	11
		JANP	2F
| 1H		INCX	1
| 2H		DECX	20		\ _E6._ (24-N)
		CMPX	=3=
		JLE	* 2+
		DECX	30
		STX	N(0:2)
		LDAN	N(0:2)		\ _E7._
		ADD	Dplus3
		SRAX	5
		DIV	=7=
		SLAX	5
| N		INCA	0		\ 31-N
		JANN	1F
		CHAR
		LDA	april
		JMP	2F
| 1H		DECA	31
		CHAR	
		LDA	march
| 2H		JBUS	*(18)
		STA	month
		STX	day(1:2)
		LDA	Y
		CHAR
		STX	year
		OUT	ans(18)		\ print
| eastx		JMP	*		\ Return to main program

| start		LDX	=1950=
		JMP	easter
		LDX	Y
		INCX	1
		CMPX	=2000=
		JLE	easter 1+	\ we already linked once :-)
		HLT
		END	start		\ wrap up assembly

			        (* End of File *)

-- output ---------------------------------------------------------------

 IP = 1098 breakpoint = -1  dumploc = 0  eusecs = 59727  ovf  cmp G int N
-------------------------------------------------------------------------
 rA = [+30|30|30|30|30] "00000" value: 511305630
 rX = [+00|00|00|31|17] "   1P" value: 2001
rI1 = [+0000] +---------------------------------------------------...
rI2 = [+0000] | 0000 : [+00|00|00|00|00] "     " value: 0
rI3 = [+0000] | 0001 : [+00|00|00|00|00] "     " value: 0
rI4 = [+0000] | 0002 : [+00|00|00|00|00] "     " value: 0
rI5 = [+0000] | 0003 : [+00|00|00|00|00] "     " value: 0
rI6 = [+0000] | 0004 : [+00|00|00|00|00] "     " value: 0
 rJ = [+1092] : 0005 : [+00|00|00|00|00] "     " value: 0

     28   MARCH     01964
     27   MARCH     01965
     02   APRIL     01966
     01   APRIL     01967
     30   MARCH     01968
     29   MARCH     01969
     28   MARCH     01970
     27   MARCH     01971
     01   APRIL     01972
     31   MARCH     01973
     30   MARCH     01974
     29   MARCH     01975
     27   MARCH     01976
     02   APRIL     01977
     01   APRIL     01978
     31   MARCH     01979
     29   MARCH     01980
     28   MARCH     01981
     27   MARCH     01982
     02   APRIL     01983
     31   MARCH     01984
     30   MARCH     01985
     29   MARCH     01986
     28   MARCH     01987
     02   APRIL     01988
     01   APRIL     01989
     31   MARCH     01990
     30   MARCH     01991
     28   MARCH     01992
     27   MARCH     01993
     02   APRIL     01994
     01   APRIL     01995
     30   MARCH     01996
     29   MARCH     01997
     28   MARCH     01998
     27   MARCH     01999
     01   APRIL     02000
MIX halted.

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

#18325

Anton Ertl wrote:

> Richard Owlett <rowlett@pcnetinc.com> writes:
>>A. K. wrote:
>>> But does it help students to understand the
>>> system by memorizing its machine instructions?
> 
> In itself, no.  But there's more to learning machine-level programming
> than learning the machine instructions.  You learn about memory and
> addresses, bits, bytes, words, and how they are related to data.  It
> is necessary to learn some assembly language to make all this
> concrete.
> 
> Forth might be a viable replacement for assembly language, as it also
> exposes these low-level concepts, but assembly/machine language has
> the advantage that everything is based on it.

Since Forth simplifies the machine, it is probably an easy teaching 
instrument.  Forth's interactive nature makes it easier to get a hang of 
these things than writing an assembler program.

At TU Munich, when I was a student, the teaching aid was an assembly 
language derived from the VAX.  The ultra-CISC assembly language.  They 
had a very slow simulator for it, which was only a crude monitor into 
the system, displaying registers an a bit of memory.

If I would develop a machine language course, I would probably start 
with Forth so that the students get the ideas of what bytes and words 
and memory is, and how to examine that (e.g. how a little endian 64 bit 
word looks like broken down into bytes, and therefore why the address is 
a multiple of 8), and then use that Forth to dig down one level further 
into assembly language, a real one, e.g. x86_64 assembler (an entry 
course doesn't have to teach all and every instruction, just the ones 
which you need - that's not that much, push pop call j<cc> ret mov xor 
and or add sub mul lea test are a good subset).  That will stay around 
for long enough that I don't have to update my course each year ;-).

>>Donald E. Knuth apparently thought the concept important
>>enough to create MIX.
>>  [ _The Art of Computer Programming_ , Vol 1 - Fundamental
>>Algorithms, 2nd Edition , c1973, p xi]
> 
> One might say that this was long ago, but more recently he created
> MMIX for reworking TAoCP.

Yes, but that is just a rework, it would be fairly fundamental if he 
changed from a machine model to a high level programming language.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#18482

On Friday, December 28, 2012 2:56:35 PM UTC-8, Bernd Paysan wrote:
> Anton Ertl wrote:
> 
> 
> 
> > Richard Owlett <rowlett@pcnetinc.com> writes:
> 
> >>A. K. wrote:
> 
> >>> But does it help students to understand the
> 
> >>> system by memorizing its machine instructions?
> 
> > 
> 
> > In itself, no.  But there's more to learning machine-level programming
> 
> > than learning the machine instructions.  You learn about memory and
> 
> > addresses, bits, bytes, words, and how they are related to data.  It
> 
> > is necessary to learn some assembly language to make all this
> 
> > concrete.
> 
> > 
> 
> > Forth might be a viable replacement for assembly language, as it also
> 
> > exposes these low-level concepts, but assembly/machine language has
> 
> > the advantage that everything is based on it.
> 
> 
> 
> Since Forth simplifies the machine, it is probably an easy teaching 
> 
> instrument.  Forth's interactive nature makes it easier to get a hang of 
> 
> these things than writing an assembler program.
> 
> 
> 
> At TU Munich, when I was a student, the teaching aid was an assembly 
> 
> language derived from the VAX.  The ultra-CISC assembly language.  They 
> 
> had a very slow simulator for it, which was only a crude monitor into 
> 
> the system, displaying registers an a bit of memory.
> 
> 
> 
> If I would develop a machine language course, I would probably start 
> 
> with Forth so that the students get the ideas of what bytes and words 
> 
> and memory is, and how to examine that (e.g. how a little endian 64 bit 
> 
> word looks like broken down into bytes, and therefore why the address is 
> 
> a multiple of 8), and then use that Forth to dig down one level further 
> 
> into assembly language, a real one, e.g. x86_64 assembler (an entry 
> 
> course doesn't have to teach all and every instruction, just the ones 
> 
> which you need - that's not that much, push pop call j<cc> ret mov xor 
> 
> and or add sub mul lea test are a good subset).  That will stay around 
> 
> for long enough that I don't have to update my course each year ;-).
> 
> 
> 
> >>Donald E. Knuth apparently thought the concept important
> 
> >>enough to create MIX.
> 
> >>  [ _The Art of Computer Programming_ , Vol 1 - Fundamental
> 
> >>Algorithms, 2nd Edition , c1973, p xi]
> 
> > 
> 
> > One might say that this was long ago, but more recently he created
> 
> > MMIX for reworking TAoCP.
> 
> 
> 
> Yes, but that is just a rework, it would be fairly fundamental if he 
> 
> changed from a machine model to a high level programming language.
> 
> 
> 
> -- 
> 
> Bernd Paysan
> 
> "If you want it done right, you have to do it yourself"
> 
> http://bernd-paysan.de/

would you ever write a book about how to learn forth and use it for common taskss?

I wish jeff fox had,,,,, and you are still alive,... please write one.

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

#18573

Bernd Paysan <bernd.paysan@gmx.de> writes:
>If I would develop a machine language course, I would probably start 
>with Forth so that the students get the ideas of what bytes and words 
>and memory is, and how to examine that (e.g. how a little endian 64 bit 
>word looks like broken down into bytes, and therefore why the address is 
>a multiple of 8), and then use that Forth to dig down one level further 
>into assembly language, a real one, e.g. x86_64 assembler (an entry 
>course doesn't have to teach all and every instruction, just the ones 
>which you need - that's not that much, push pop call j<cc> ret mov xor 
>and or add sub mul lea test are a good subset).  That will stay around 
>for long enough that I don't have to update my course each year ;-).

That sounds like a good plan if you have a full-blown computer
architecture course.  Unfortunately we don't have that anymore at TU
Wien, so we have to compress things a bit more.

>>>Donald E. Knuth apparently thought the concept important
>>>enough to create MIX.
>>>  [ _The Art of Computer Programming_ , Vol 1 - Fundamental
>>>Algorithms, 2nd Edition , c1973, p xi]
>> 
>> One might say that this was long ago, but more recently he created
>> MMIX for reworking TAoCP.
>
>Yes, but that is just a rework, it would be fairly fundamental if he 
>changed from a machine model to a high level programming language.

Depends what you mean by "high-level".  I expected him to change to C
for reworking the books.  I did not think that reworking from MIX to
MMIX is any easier or less fundamental than from MIX to C.

But given the tendencies to make C a language that is incapable of
expressing low-level things (not that this makes C any higher-level),
maybe Knuth was right in sticking with an assembly language (Forth
might be another option).

In particular, I recently wrote a hash function in (what I consider) C
as follows:

typedef unsigned int uint128_t __attribute__((__mode__(TI)));
#define hashmult 13493690561280548289ULL

unsigned long hash(char *addr, size_t len)
{
  /* assumptions: 1) unaligned accesses work 2) little-endian 3) 7 bytes
     beyond last byte can be accessed */
  uint128_t x=0, w;
  size_t i, shift;
  for (i=0; i+7<len; i+=8) {
    w = *(unsigned long *)(addr+i);
    x = (x + w)*hashmult;
  }
  if (i<len) {
    shift = (i+8-len)*8;
    /* printf("len=%d, shift=%d\n",len, shift);*/
    w = (*(unsigned long *)(addr+i))<<shift;
    x = (x + w)*hashmult;
  }
  return x+(x>>64);
}

While the version of gcc I used for this happened to understand this
code as intended and compiled it correctly, I am sure the
self-proclaimed "people who have knowledge about C" consider it
meaningless and would be happy if gcc miscompiled this code.  And I
don't think that there is a way to write this in standard C that
results in code that is as efficient, so maybe the way to go is really
to use assembly language.

Or, to get back on topic, Forth.  We can just write this in Forth with
the same assumptions, and it would be equally non-standard, but in
Forth we do not have this attitude that non-standard programs are
meaningless and may be freely miscompiled.  Still, what is missing
from Forth to write such code portably *and* efficiently?  I think
that unaligned access is the main thing.  There have been proposals
for that, but none has been accepted yet.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2012: http://www.euroforth.org/ef12/

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

#18575

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>If I would develop a machine language course, I would probably start 
>>with Forth so that the students get the ideas of what bytes and words 
>>and memory is, and how to examine that (e.g. how a little endian 64 bit 
>>word looks like broken down into bytes, and therefore why the address is 
>>a multiple of 8), and then use that Forth to dig down one level further 
>>into assembly language, a real one, e.g. x86_64 assembler (an entry 
>>course doesn't have to teach all and every instruction, just the ones 
>>which you need - that's not that much, push pop call j<cc> ret mov xor 
>>and or add sub mul lea test are a good subset).  That will stay around 
>>for long enough that I don't have to update my course each year ;-).
> 
> That sounds like a good plan if you have a full-blown computer
> architecture course.  Unfortunately we don't have that anymore at TU
> Wien, so we have to compress things a bit more.
> 
>>>>Donald E. Knuth apparently thought the concept important
>>>>enough to create MIX.
>>>>  [ _The Art of Computer Programming_ , Vol 1 - Fundamental
>>>>Algorithms, 2nd Edition , c1973, p xi]
>>> 
>>> One might say that this was long ago, but more recently he created
>>> MMIX for reworking TAoCP.
>>
>>Yes, but that is just a rework, it would be fairly fundamental if he 
>>changed from a machine model to a high level programming language.
> 
> Depends what you mean by "high-level".  I expected him to change to C
> for reworking the books.  I did not think that reworking from MIX to
> MMIX is any easier or less fundamental than from MIX to C.

You can't do it because there are no instruction timings for C, so no
way to compare performance.

> But given the tendencies to make C a language that is incapable of
> expressing low-level things (not that this makes C any higher-level),
> maybe Knuth was right in sticking with an assembly language (Forth
> might be another option).
> 
> In particular, I recently wrote a hash function in (what I consider) C
> as follows:
> 
> typedef unsigned int uint128_t __attribute__((__mode__(TI)));
> #define hashmult 13493690561280548289ULL
> 
> unsigned long hash(char *addr, size_t len)
> {
>  /* assumptions: 1) unaligned accesses work 2) little-endian 3) 7 bytes
>     beyond last byte can be accessed */
>  uint128_t x=0, w;
>  size_t i, shift;
>  for (i=0; i+7<len; i+=8) {
>    w = *(unsigned long *)(addr+i);
>    x = (x + w)*hashmult;
>  }
>  if (i<len) {
>    shift = (i+8-len)*8;
>    /* printf("len=%d, shift=%d\n",len, shift);*/
>    w = (*(unsigned long *)(addr+i))<<shift;
>    x = (x + w)*hashmult;
>  }
>  return x+(x>>64);
> }
> 
> While the version of gcc I used for this happened to understand this
> code as intended and compiled it correctly, I am sure the
> self-proclaimed "people who have knowledge about C" consider it
> meaningless and would be happy if gcc miscompiled this code.  And I
> don't think that there is a way to write this in standard C that
> results in code that is as efficient,

This is no less efficient in 4.6.3, and mostly legal C:

typedef unsigned int uint128_t __attribute__((__mode__(TI)));
#define hashmult 13493690561280548289ULL

unsigned long hash(char *addr, size_t len)
{
  uint128_t x=0;
  unsigned long w;
  size_t i, shift;
  for (i=0; i+7<len; i+=8) {
    memcpy(&w, addr+i, sizeof w);
    x = (x + w)*hashmult;
  }
  if (i<len) {
    shift = (i+8-len)*8;
    /* printf("len=%d, shift=%d\n",len, shift);*/
    memcpy(&w, addr+i, sizeof w);
    x = (x + (w<<shift))*hashmult;
  }
  return x+(x>>64);
}

Andrew.

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

#19051

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Depends what you mean by "high-level".  I expected him to change to C
>> for reworking the books.  I did not think that reworking from MIX to
>> MMIX is any easier or less fundamental than from MIX to C.
>
>You can't do it because there are no instruction timings for C, so no
>way to compare performance.

He could have made timing assignments for various operations in C,
just like he did for MMIX.  Sure it's not reality, but neither is
MMIX.

>> In particular, I recently wrote a hash function in (what I consider) C
>> as follows:
>> 
>> typedef unsigned int uint128_t __attribute__((__mode__(TI)));
>> #define hashmult 13493690561280548289ULL
>> 
>> unsigned long hash(char *addr, size_t len)
>> {
>>  /* assumptions: 1) unaligned accesses work 2) little-endian 3) 7 bytes
>>     beyond last byte can be accessed */
>>  uint128_t x=0, w;
>>  size_t i, shift;
>>  for (i=0; i+7<len; i+=8) {
>>    w = *(unsigned long *)(addr+i);
>>    x = (x + w)*hashmult;
>>  }
>>  if (i<len) {
>>    shift = (i+8-len)*8;
>>    /* printf("len=%d, shift=%d\n",len, shift);*/
>>    w = (*(unsigned long *)(addr+i))<<shift;
>>    x = (x + w)*hashmult;
>>  }
>>  return x+(x>>64);
>> }
>> 
>> While the version of gcc I used for this happened to understand this
>> code as intended and compiled it correctly, I am sure the
>> self-proclaimed "people who have knowledge about C" consider it
>> meaningless and would be happy if gcc miscompiled this code.  And I
>> don't think that there is a way to write this in standard C that
>> results in code that is as efficient,
>
>This is no less efficient in 4.6.3, and mostly legal C:

What is the difference between "mostly legal" and "meaningless"?

>typedef unsigned int uint128_t __attribute__((__mode__(TI)));
>#define hashmult 13493690561280548289ULL
>
>unsigned long hash(char *addr, size_t len)
>{
>  uint128_t x=0;
>  unsigned long w;
>  size_t i, shift;
>  for (i=0; i+7<len; i+=8) {
>    memcpy(&w, addr+i, sizeof w);

[Not quite correct because w is wider than an unsigned long, but let's
assume you get it right].

Yes, that is probably a standard-compliant way to perform an unaligned
access.  And it (actually the correct version) indeed compiles to a
single mov instruction on AMD64.

However, that is contrary to my mental model of C performance, which
says that function calls have a much higher cost than a memory access
through a pointer.  One might say that I need to adjust my mental
model, but if I use memcpy() with a non-constant third argument, it
really is slow.  A low-level language also needs understandable
performance; fast operations should be available through language
features, not through compiler optimization of special expressions of
otherwise-slow features.

Yes, Forth does not provide language features for unaligned access,
either.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2012: http://www.euroforth.org/ef12/

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

#19056

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Depends what you mean by "high-level".  I expected him to change to C
>>> for reworking the books.  I did not think that reworking from MIX to
>>> MMIX is any easier or less fundamental than from MIX to C.
>>
>>You can't do it because there are no instruction timings for C, so no
>>way to compare performance.
> 
> He could have made timing assignments for various operations in C,
> just like he did for MMIX.  Sure it's not reality, but neither is
> MMIX.

Perhaps, but to do so you'd have to convert each C expression into a
sequence of instructions.  It's easier to see what is going on in
assembly.

>>> In particular, I recently wrote a hash function in (what I consider) C
>>> as follows:
>>> 
>>> typedef unsigned int uint128_t __attribute__((__mode__(TI)));
>>> #define hashmult 13493690561280548289ULL
>>> 
>>> unsigned long hash(char *addr, size_t len)
>>> {
>>>  /* assumptions: 1) unaligned accesses work 2) little-endian 3) 7 bytes
>>>     beyond last byte can be accessed */
>>>  uint128_t x=0, w;
>>>  size_t i, shift;
>>>  for (i=0; i+7<len; i+=8) {
>>>    w = *(unsigned long *)(addr+i);
>>>    x = (x + w)*hashmult;
>>>  }
>>>  if (i<len) {
>>>    shift = (i+8-len)*8;
>>>    /* printf("len=%d, shift=%d\n",len, shift);*/
>>>    w = (*(unsigned long *)(addr+i))<<shift;
>>>    x = (x + w)*hashmult;
>>>  }
>>>  return x+(x>>64);
>>> }
>>> 
>>> While the version of gcc I used for this happened to understand this
>>> code as intended and compiled it correctly, I am sure the
>>> self-proclaimed "people who have knowledge about C" consider it
>>> meaningless and would be happy if gcc miscompiled this code.  And I
>>> don't think that there is a way to write this in standard C that
>>> results in code that is as efficient,
>>
>>This is no less efficient in 4.6.3, and mostly legal C:
> 
> What is the difference between "mostly legal" and "meaningless"?

It doesn't have any undefined behaviour.  However, the exact result of
the hash is implementation-dependent.

>>typedef unsigned int uint128_t __attribute__((__mode__(TI)));
>>#define hashmult 13493690561280548289ULL
>>
>>unsigned long hash(char *addr, size_t len)
>>{
>>  uint128_t x=0;
>>  unsigned long w;
>>  size_t i, shift;
>>  for (i=0; i+7<len; i+=8) {
>>    memcpy(&w, addr+i, sizeof w);
> 
> [Not quite correct because w is wider than an unsigned long, but let's
> assume you get it right].

[ I don't understand this parenthetical remark.  You said

   w = *(unsigned long *)(addr+i);
   x = (x + w)*hashmult;

I presume this is intended to read an unsigned long into the low-order
bits of w, a uint128.

and I said

   memcpy(&w, addr+i, sizeof w);
   x = (x + w)*hashmult;

which is a legal way to do what I think you intended.  w, an unsigned
long, is promoted to uint128 before adding it to x. ]

> Yes, that is probably a standard-compliant way to perform an unaligned
> access.  And it (actually the correct version) 

The correct version of what?

> indeed compiles to a single mov instruction on AMD64.
> 
> However, that is contrary to my mental model of C performance, which
> says that function calls have a much higher cost than a memory access
> through a pointer.

Your mental model of C performance is wrong.

> One might say that I need to adjust my mental model, but if I use
> memcpy() with a non-constant third argument, it really is slow. 

As you'd expect, no?

> A low-level language also needs understandable performance; fast
> operations should be available through language features, not
> through compiler optimization of special expressions of
> otherwise-slow features.

This doesn't make any sense.  A read of a word-sized object into a
local is fast, regardless of whether it's done by a memcpy() or an
assignment, as long as the machine can actually do the unaligned
access.

> Yes, Forth does not provide language features for unaligned access,
> either.

Either?  C clearly does.

Andrew.

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

#19080

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> Depends what you mean by "high-level".  I expected him to change to C
>>>> for reworking the books.  I did not think that reworking from MIX to
>>>> MMIX is any easier or less fundamental than from MIX to C.
>>>
>>>You can't do it because there are no instruction timings for C, so no
>>>way to compare performance.
>> 
>> He could have made timing assignments for various operations in C,
>> just like he did for MMIX.  Sure it's not reality, but neither is
>> MMIX.
>
>Perhaps, but to do so you'd have to convert each C expression into a
>sequence of instructions.  It's easier to see what is going on in
>assembly.

For algorithms?  Then I wonder why people program algorithms in other
languages than assembly.  Many even write articles and books that
present algorithms in languages other than assembly.  Wasn't Algol
even named as a language for writing algorithms?

Concerning performance, given the way that CPUs work these days, you
don't see that much more that's relevant to performance in assembly
language (or even machine language), either.

>> What is the difference between "mostly legal" and "meaningless"?
>
>It doesn't have any undefined behaviour.  However, the exact result of
>the hash is implementation-dependent.

I wouldn't be surprised if it was flamed if I posted this code in
comp.lang.c (at least pointing out non-standardness was the only thing
that posters there did the last time I posted there).

>[ I don't understand this parenthetical remark.

Sorry, I had not caught that you had changed the type of w.

>> However, that is contrary to my mental model of C performance, which
>> says that function calls have a much higher cost than a memory access
>> through a pointer.
>
>Your mental model of C performance is wrong.

It is?  You mean, that every version of every C compiler with any
optimization options will compile this memcpy() to a simple unaligned
memory-to-register load?

>> One might say that I need to adjust my mental model, but if I use
>> memcpy() with a non-constant third argument, it really is slow. 
>
>As you'd expect, no?

Yes.  So my mental model of C performance is not so wrong after all.

>> A low-level language also needs understandable performance; fast
>> operations should be available through language features, not
>> through compiler optimization of special expressions of
>> otherwise-slow features.
>
>This doesn't make any sense.  A read of a word-sized object into a
>local is fast, regardless of whether it's done by a memcpy() or an
>assignment, as long as the machine can actually do the unaligned
>access.

No, it's only fast with memcpy() if the compiler can perform this
optimization in general and if if succeeds in performing this
optimization in this particular case.  If it does not, not only will
the call to memcpy() be slow, but other accesses to this local will be
slow, too, because the local is forced into memory.

>> Yes, Forth does not provide language features for unaligned access,
>> either.
>
>Either?  C clearly does.

Not as I mean language feature in this context.  The unary * is a
language feature in C.  Function calls are a language feature.  A
special pattern of calling a library function is not a language
feature in this sense.

If we use your sense of "language feature", we have it in Forth, too:
MOVE.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2012: http://www.euroforth.org/ef12/

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

#19085

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>> Depends what you mean by "high-level".  I expected him to change to C
>>>>> for reworking the books.  I did not think that reworking from MIX to
>>>>> MMIX is any easier or less fundamental than from MIX to C.
>>>>
>>>>You can't do it because there are no instruction timings for C, so no
>>>>way to compare performance.
>>> 
>>> He could have made timing assignments for various operations in C,
>>> just like he did for MMIX.  Sure it's not reality, but neither is
>>> MMIX.
>>
>>Perhaps, but to do so you'd have to convert each C expression into a
>>sequence of instructions.  It's easier to see what is going on in
>>assembly.
> 
> For algorithms?

No, for exact timing.

> Concerning performance, given the way that CPUs work these days, you
> don't see that much more that's relevant to performance in assembly
> language (or even machine language), either.

Indeed not.

>>> However, that is contrary to my mental model of C performance, which
>>> says that function calls have a much higher cost than a memory access
>>> through a pointer.
>>
>>Your mental model of C performance is wrong.
> 
> It is?  You mean, that every version of every C compiler with any
> optimization options will compile this memcpy() to a simple unaligned
> memory-to-register load?

No, I mean that on some processors unaligned loads are hard, and on
some they're not.  You have to know which you're using.  I would
expect a C compiler to turn this into a load if it can be done that
way, but some C compilers might not do that.  Some C compilers
generate subroutine calls for arithmetic operations.  There isn't a
simple 1:1 mapping to instructions.

>>> A low-level language also needs understandable performance; fast
>>> operations should be available through language features, not
>>> through compiler optimization of special expressions of
>>> otherwise-slow features.
>>
>>This doesn't make any sense.  A read of a word-sized object into a
>>local is fast, regardless of whether it's done by a memcpy() or an
>>assignment, as long as the machine can actually do the unaligned
>>access.
> 
> No, it's only fast with memcpy() if the compiler can perform this
> optimization in general and if if succeeds in performing this
> optimization in this particular case.  If it does not, not only will
> the call to memcpy() be slow, but other accesses to this local will be
> slow, too, because the local is forced into memory.

Well, yes, but that's true of everything a compiler does.

>>> Yes, Forth does not provide language features for unaligned access,
>>> either.
>>
>>Either?  C clearly does.
> 
> Not as I mean language feature in this context.  The unary * is a
> language feature in C.  Function calls are a language feature.  A
> special pattern of calling a library function is not a language
> feature in this sense.

I think you're making this up as you go along.  memcpy() to a local is
a language feature.

> If we use your sense of "language feature", we have it in Forth, too:
> MOVE.

No, 'cos you can't get the address of a local.

Andrew.

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

#19089

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>Perhaps, but to do so you'd have to convert each C expression into a
>>>sequence of instructions.  It's easier to see what is going on in
>>>assembly.
>> 
>> For algorithms?
>
>No, for exact timing.

There's no exact timing with assembly language on modern CPUs, either,
and even if Knuth defines one for MMIX, it does not transfer any
better to real machines than a performance model based on C (or what C
used to be).  So there is no obvious point in using MMIX, except of
course that C is mutating into a language that gives us the
intersection of the capabilities of low-level and high-level
languages.

>>>> However, that is contrary to my mental model of C performance, which
>>>> says that function calls have a much higher cost than a memory access
>>>> through a pointer.
>>>
>>>Your mental model of C performance is wrong.
>> 
>> It is?  You mean, that every version of every C compiler with any
>> optimization options will compile this memcpy() to a simple unaligned
>> memory-to-register load?
>
>No, I mean that on some processors unaligned loads are hard, and on
>some they're not.

I knew beforehand that on some architectures unaligned loads take a
few instructions (three on Alpha IIRC).  I expected beforehand that my
code would cause an exception on such machines (I even documented that
dependency), so I did not expect that code to perform on such machines
at all.  Why did you say that my mental model of C performance is
wrong?

> Some C compilers
>generate subroutine calls for arithmetic operations.

Sure, if the architecture does not have a division instruction, a
division subroutine will be called.  That's more a property of the
architecture than of the C compiler.

>There isn't a
>simple 1:1 mapping to instructions.

In a real low-level language (like the GNU C compiled by gcc 2.x) the
mapping is not 1:1, but it's relatively simple.  The kind of
unpredictable performance that you get with stuff like the memcpy()
trick is removing this important feature of C, which leads me to the
"intersection" assessment above.

>> No, it's only fast with memcpy() if the compiler can perform this
>> optimization in general and if if succeeds in performing this
>> optimization in this particular case.  If it does not, not only will
>> the call to memcpy() be slow, but other accesses to this local will be
>> slow, too, because the local is forced into memory.
>
>Well, yes, but that's true of everything a compiler does.

No, that's not true of proper language features.  Show me a compiler
for, say, AMD64 that compiles a function call for *p, where p points
to an unsigned long.

>> Not as I mean language feature in this context.  The unary * is a
>> language feature in C.  Function calls are a language feature.  A
>> special pattern of calling a library function is not a language
>> feature in this sense.
>
>I think you're making this up as you go along.  memcpy() to a local is
>a language feature.

K&R (2nd Ed.) never mentioned it, and I also never saw it in any other
books about C.

>> If we use your sense of "language feature", we have it in Forth, too:
>> MOVE.
>
>No, 'cos you can't get the address of a local.

That's not necessary.

: @u ( addr -- x ) \ untested
  1 cells allocate throw tuck 1 cells move dup @ swap free throw ;

Any Forth compiler written with the same perverse mindset as the GCC
maintainers (and maybe other C compiler writers) are employing will
compile that into a simple unaligned load.  I think, though, that it's
better to just define @U or something similar to perform an unaligned
fetch, instead of letting the compiler jump through these kinds of
hoops.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2012: http://www.euroforth.org/ef12/

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

#19093

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>Perhaps, but to do so you'd have to convert each C expression into a
>>>>sequence of instructions.  It's easier to see what is going on in
>>>>assembly.
>>> 
>>> For algorithms?
>>
>>No, for exact timing.
> 
> There's no exact timing with assembly language on modern CPUs, either,
> and even if Knuth defines one for MMIX, it does not transfer any
> better to real machines than a performance model based on C (or what C
> used to be).

But when discussing algorithms you need something better than big-O
notation when talking about efficiency, so you need to be able to talk
about the the time taken by specific operations, and to do that you
need to be able to talk about instructions.  For example, the reason
why quicksort is so great is that the inner loop can be done very
efficiently.  All the other books on algorithms I've seen punt on this
issue; credit to Knuth.

And of course, this won't correspond exactly to any particular
modern CPU, but some people's mental machinery needs something
concrete.

>>>>> However, that is contrary to my mental model of C performance, which
>>>>> says that function calls have a much higher cost than a memory access
>>>>> through a pointer.
>>>>
>>>>Your mental model of C performance is wrong.
>>> 
>>> It is?  You mean, that every version of every C compiler with any
>>> optimization options will compile this memcpy() to a simple unaligned
>>> memory-to-register load?
>>
>>No, I mean that on some processors unaligned loads are hard, and on
>>some they're not.
> 
> I knew beforehand that on some architectures unaligned loads take a
> few instructions (three on Alpha IIRC).  I expected beforehand that
> my code would cause an exception on such machines (I even documented
> that dependency), so I did not expect that code to perform on such
> machines at all.  Why did you say that my mental model of C
> performance is wrong?

Because that model does not correspond with reality.  What other test
of a model is there?

>>There isn't a simple 1:1 mapping to instructions.
> 
> In a real low-level language (like the GNU C compiled by gcc 2.x) the
> mapping is not 1:1, but it's relatively simple.  The kind of
> unpredictable performance that you get with stuff like the memcpy()
> trick is removing this important feature of C, which leads me to the
> "intersection" assessment above.

I guess the difference here is our expectations.  I've never really
thought of C as being like that.  One programmer's bug is another
programmer's feature.

>>> No, it's only fast with memcpy() if the compiler can perform this
>>> optimization in general and if if succeeds in performing this
>>> optimization in this particular case.  If it does not, not only will
>>> the call to memcpy() be slow, but other accesses to this local will be
>>> slow, too, because the local is forced into memory.
>>
>>Well, yes, but that's true of everything a compiler does.
> 
> No, that's not true of proper language features.  Show me a compiler
> for, say, AMD64 that compiles a function call for *p, where p points
> to an unsigned long.

Ah, OK.  :-)  Of course, you can argue reductio ad absurdum if you
want.  But this is an entirely circular argument, defining a "proper
language feature" to suit yourself.

>>> Not as I mean language feature in this context.  The unary * is a
>>> language feature in C.  Function calls are a language feature.  A
>>> special pattern of calling a library function is not a language
>>> feature in this sense.
>>
>>I think you're making this up as you go along.  memcpy() to a local is
>>a language feature.
> 
> K&R (2nd Ed.) never mentioned it, and I also never saw it in any other
> books about C.

It's there, though.

>>> If we use your sense of "language feature", we have it in Forth, too:
>>> MOVE.
>>
>>No, 'cos you can't get the address of a local.
> 
> That's not necessary.
> 
> : @u ( addr -- x ) \ untested
>  1 cells allocate throw tuck 1 cells move dup @ swap free throw ;
> 
> Any Forth compiler written with the same perverse mindset as the GCC
> maintainers (and maybe other C compiler writers) are employing will
> compile that into a simple unaligned load.
> I think, though, that it's better to just define @U or something
> similar to perform an unaligned fetch, instead of letting the
> compiler jump through these kinds of hoops.

That would be much more Forthly.

Andrew.

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

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

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

csiph-web