__volatile__ __asm__

volatile is a C keyword, and programmers know better than using asm as an identifier. Why do people insist on using double underscores around them, especially Linux kernel developers?

Also, why do people use things like __attribute__((aligned(n))) instead of defining a macro ALIGNED(n)?

because it's pythonic, which means it's correct

use volitile to make it safe thread.

>>2-3
/prog/ is shit.

>>1

Some old compilers do not understand the volatile keyword. (I know, this is no excuse, but "kernel developers" are rather ill-evolved people.)

And why should one bother with defining a macro?

>>5
And why should one bother with defining a macro?
It looks better and it's shorter to type -- I write kernel code so it appears a lot.

Why doesn't C have abstract?

No wonder why you neckbeards never got an ENTERPRISE job.

>>6
Unless the code is intended to be compiled on other compilers, so that the macro might have another definition, I would not define such a macro. But I agree it looks better than the ridiculous __attribute__ syntax.

>>6
I write kernel code so it appears a lot.
You are retarded. In fact this entire thread is retarded.

"Declaring your variables volatile will have no useful effect, and will simply cause your code to run a *lot* slower when you turn on optimisation in your compiler." - Bryan O' Sullivan

"...the use of volatile accomplishes nothing but to prevent the compiler from making useful and desirable optimizations, providing no help whatsoever in making code "thread safe". " - David Butenhof

http://software.intel.com/en-us/blogs/2007/11/30/volatile-almost-useless-for-multi-threaded-programming/

>>9

I pretty much believe you are retarded.

volatile has legitimate uses in hardware programming, and (competent) kernel developers are well aware of those uses. No one has said anything about volatile and multithreading.

Also, you're just parroting information from other threads without even knowing what they're about.

>>7[code]'
>Why doesn't C have abstract
>Implying a non-oop lanaguage would have a oop keyword
[code]

>>10
volatile has legitimate uses in hardware programming, and (competent) kernel developers are well aware of those uses.
vs

I write kernel code so it appears a lot.

Nope, it's definitely you!

>>10
http://kernel.org/doc/Documentation/volatile-considered-harmful.txt

It reduces the likelihood of code collision.

The right
>way to perform a busy wait is:

  >  while (my_variable != what_i_want)
   >     cpu_relax();

>>15
Of course, busy-
waiting is generally an anti-social act to begin with.

what do you think the correct way is?

inb4

while(my_varaible != what_i_what);

>>16
Not writing yourself into such "busy waiting" parts in the first place.
make program which don't depend on var A being checked, and instead continue the rest of the program

>>8
My main targets are gcc, clang and maybe tcc at a later point -- both clang and tcc tend to emulate gcc's behaviour on things, so the only motive is really of aesthetic nature.

>>9-13,16
The main legitimate use of volatile nowadays is to prevent the compiler from removing asm sections or moving them around.

>>15,17
Fuck off you fucking shiteater.

>>18
compiler from removing asm sections or moving them around.
why would a compiler do this?

isn't gcc the only shitty one that does?

>>18
tcc if you want compile speed
gcc if you want optimization
clang if you want gcc with improved compile speed

So, why do we need all these inferior ad-hoc languages, when there is Lisp? Why not have a superior low level Lisp DSL for kernel development, instead of error-prone and bloated C/C++ toolchain? It clear that C/C++ has no future and is going to die.

>>21
low level Lisp

then you'd just get C with abusive ( )

>>22
Nope. You'll get a macro assembler with Lisp syntax.

>>21
Lisp's syntax is horrible and unreadable.  Besides, I intend to run a high-level language atop of my kernel (something more readable, perhaps along the lines of brainfuck).

>>24
Lisp's syntax is horrible and unreadable.
No.

I intend to run a high-level language atop of my kernel (something more readable, perhaps along the lines of brainfuck).
Macro assembly Lisp could be easily extended into higher-level Lisp - just use it to implement GC and eval. And EVAL effectively acts as a security ensurer, so you can safely use single address space microkernel with uber-fast message passing.

>>25
You are under arrest for using the words "eval" and "fast" in the same sentence.

Also, Lisp syntax IS horrible and unreadable no matter how you look at it. I strongly believe that it should be the AST of a properly-syntaxed language.

asm is probably the only language that made sense and was easy to read

R.I.P asm /prog/ers

>>26
No.

>>27
asm uses prefix notation. Just like Lisp.

>>28
Fuck off and die already you fucking piece of shit.  I'd love so much to punch you in your little faggot face right now, you just have no idea.  Also, asm statements don't nest, which is exactly what makes asm so readable and your liquid shit language so unreadable.

>>28
you can prefix notation in C with macros

>>29
No.

>>30
Non uniform.

>>31
Fuck off and die, fagstain.

>>32
When you learn how to debate properly, maybe I will

just use python

>>33
I already said what I had to say: Common Lisp is an ugly manbeast obviously designed by a committee, a very long time ago, and Scheme is underspecified (standard libraries?) and overcomplicated at times (macros anyone?). Both, as Lisps, share the same anti-feature that is Sexp-based syntax (with the aggravating factor that the language even encourages the proliferation of extra parentheses and deeper nesting levels), which results in code unreadability through lack of visual cues. I said it before and I'll say it again, stick a proper syntax on Lisp and you'll probably have something quite very decent, assuming the underlying Lisp isn't braindead (Lisp-1, delimited continuations, etc.) -- and yes, I know you can easily write a Lisp-1 interpreter in any Lisp-2, so don't bother arguing about the nature of the world `underlying'.

Uniformity is a great thing for macros (let's face it, it's the only feature that really needs them), and I believe you could still have macros equivalent in power with non-Sexp based syntax.

Will you fuck off and die now?

>>35

This one /prog/rammer speaks -- alas! -- the Truth.

>>35
If you're so sure, whip up a #lang in racket. I bet you will find no one cares, because people use lisps because of the sexps, not in spite of them.

>>35
That's actually much better. I still disagree with you in most of your opinions. I use Lisp because of sexp together with a decent editor.

>>35
Its been done many times and it never caught on.
In practice nobody whose interested in Lisp is interested in hiding the parens. McCarthy originally provided M-expressions as  a cover over the Sexps but nobody used it and worked directly with sSxps. Theres been a few other attempts. In Schemeland there was SRFI 49 which creates a FIOCScheme but that obviously never caught on.

Nobody is interested in your ScalaLisp ideas, `fagstorm'.

>>39
isn't matlab or mathematica or some shit full of mexps? It seems intuitive to some people. I don't know, I picked up sexp programming very quickly, it seemed very intuitive to me. Even when I have to program in C for work I still sketch everything out in lispy pseudocode. I don't have anything in particular against C but it isn't my language of choice.