Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go and Assembly

doxsey.net

Post reply on HN
Print view View original

91–100 of 127 posts

Re: Go and Assembly

#91

Post by burntsushi »

cpeterso wrote: post #88
vanderZwan wrote: post #29

Earlier quoted context omitted.

Well, since two of the original three developers (Pike and Thompson) were part of the Plan 9 team, it makes perfect sense that they based the compilers on the Plan 9 ones.

I see recent commits in Go's mercurial history to fix bugs on Plan 9. Is anyone at Google actually using Plan 9 to develop Go? Or is building for Plan 9 just a sanity test for maintaining cross platform code? Wikipedia says the last "stable" release of Plan 9 was in 2002, but there seem to be a number of recent forks.

There are people that don't work at Google who contribute to Go. It's an open source project.

Re: Go and Assembly

#92

Post by jholman »

TylerE wrote: post #13
dualogy wrote: post #11

Earlier quoted context omitted.

[[[EDIT: wrote this little rant before realizing you specifically refer to HN search rather than general search. Yeah why would I ever search on a specific Go topic exclusively on HN, instead of web-searching?]]] Every time a Go article comes up, the "name searchability" discussion comes up. Go's been around for some 4-5 years now, can we all come to terms with its name? Somehow whenever brainfuck-lang threads show u…

Your examples make no real sense, other than "Basic". Perl is absolutely NOT a common word. Pearl is common, but Perl is the programming language (only)

Actually, before the modern programming languages (say pre-1990 for simplicity), "perl" was just as common a word as "java" (though falling), and at one point "miranda" was substantially more so. "pearl" is only around 100x more common than "perl". "basic" is certainly FAR more common than any of the above, including "pearl".

http://books.google.com/ngrams/graph?content=java%2Cperl%2Cm...

I'll assume you've never knitted.

Re: Go and Assembly

#93

Post by strmpnk »

WalterBright wrote: post #83

Here's how to do inline assembler in D: int *_memset32(int *p, int value, size_t count) { asm { mov EDI,p ; mov EAX,value ; mov ECX,count ; mov EDX,EDI ; rep ; stosd ; mov EAX,EDX ; } } The compiler adds the function prolog/epilog for you, as well as any save/restore for used registers.

Well, this article wasn't about _inline_ assembler. Regardless, inline forms have a number of problems, the biggest one being supporting multiple platforms w/o a bunch of preprocessor noise. That doesn't stop it from being useful for certain languages but it matters less and less given how compilers behave these days.

Re: Go and Assembly

#94

Post by dualogy »

stephencanon wrote: post #54
dualogy wrote: post #12

Earlier quoted context omitted.

Yeah that was kinda my point ;)) so basically 386 users get some highly specialized hand-tuned asm optimization whereas arm and amd64 merely get a commoner's gc treatment -- or am I missing something? ;)

Several things: - The fprem1 instruction is actually a long microcode sequence and is quite slow; 26-50 cycles on SNB according to Agner Fog. Several iterations of that loop are necessary for a complete reduction of some operands. - There is no analogous instruction on arm (or really, any platform that isn't x86), anyway. - If you're using the floating-point remainder operation in a performance-sensitive context, You…

This was just a random example I picked, I'm not using that function currently. But let's just say abs(), sin(), cos()...

Re: Go and Assembly

#95

Post by WalterBright »

strmpnk wrote: post #93
WalterBright wrote: post #83

Here's how to do inline assembler in D: int *_memset32(int *p, int value, size_t count) { asm { mov EDI,p ; mov EAX,value ; mov ECX,count ; mov EDX,EDI ; rep ; stosd ; mov EAX,EDX ; } } The compiler adds the function prolog/epilog for you, as well as any save/restore for used registers.

Well, this article wasn't about _inline_ assembler. Regardless, inline forms have a number of problems, the biggest one being supporting multiple platforms w/o a bunch of preprocessor noise. That doesn't stop it from being useful for certain languages but it matters less and less given how compilers behave these days.

There is a steady drift away from using assembler even in languages that support it. Intrinsics, for example, often work better. But there are a few things where it really comes in handy.

Re: Go and Assembly

#96

Post by dualogy »

justsomedood wrote: post #40

This reminds me of a topic that had come up earlier last year: Intermitten problems with 32bit programs in go. If I remember correctly programs would crash intermittently if the initial 512MB memory block requested wasn't contiguous. Does anyone know if this still is the case? Is the solution still to always just use 64bit?

As I'm only on 64b right now, I can't quite remember whether that was fixed by 1.0.3 or will be in 1.1 -- but I'm pretty pretty sure one of these is the case.

Re: Go and Assembly

#97

Post by jgeralnik »

NateDad wrote: post #66
charlieflowers wrote: post #44

Now this is an impressive argument. Particularly the first section about the tool chain (and the assembly part is really cool too). I have been holding back because I don't like the lack of exceptions. But it occurred to me that C doesn't have anything like exceptions either, and even though that lack causes some serious irritation, the C language as a total package overcomes it and is really powerful. I don't know i…

I thought it would be a deal breaker for me, too. C/C++/C#/Python have been my standard languages... but after coding in it for a while, I love it. You never have to worry if someone downstream is going to throw an exception make your function exit before it gets to the end. That means you can write robust code without needing a ton of try/catch everywhere, or using statements (from C#) or whatever. Yes, there's some…

Don't bother with the else. Just continue with your code outside a nested block since the if returns.

Re: Go and Assembly

#98

Post by strmpnk »

WalterBright wrote: post #95
strmpnk wrote: post #93

Earlier quoted context omitted.

Well, this article wasn't about _inline_ assembler. Regardless, inline forms have a number of problems, the biggest one being supporting multiple platforms w/o a bunch of preprocessor noise. That doesn't stop it from being useful for certain languages but it matters less and less given how compilers behave these days.

There is a steady drift away from using assembler even in languages that support it. Intrinsics, for example, often work better. But there are a few things where it really comes in handy.

I wonder if we'll see more user-side emulation of intrinsics given new __attribute__ flags compilers are implementing. It certainly is easier to reason about.

Go doesn't have anything like that yet but I wouldn't be surprised if an experimental implementation is done by one of the alternate compilers being worked on.

Re: Go and Assembly

#99

Post by pkulak »

charlieflowers wrote: post #44

Now this is an impressive argument. Particularly the first section about the tool chain (and the assembly part is really cool too). I have been holding back because I don't like the lack of exceptions. But it occurred to me that C doesn't have anything like exceptions either, and even though that lack causes some serious irritation, the C language as a total package overcomes it and is really powerful. I don't know i…

I think the defer keyword more than makes up for the lack of exceptions. And you can panic, you are just not supposed to let it get out of your package; catch it and return the error.

Re: Go and Assembly

#100

Post by pkulak »

charlieflowers wrote: post #89
charlieflowers wrote: post #59

Earlier quoted context omitted.

Hmmm, interesting. The "defer" approach is a different spin on things. But yes, panic/recover does look like it would address my concerns. I never did like exceptions across package boundaries much, but inside a cohesive module I want to use them instead of a bunch of code that checks return values for error codes.

Although, another post above says it's not idiomatic, so I guess working with go means accepting the lack of an exception mechanism.

No, jlgreco had it exactly right.
Post reply on HN