Dummy Tries to Learn Programming

[goto124]

So, for whatever reason, I decided to start learning the C programming language!

Or something.

Anyway, I'm starting from Ground Zero- I know nothing about computer programming. I just read somewhere that C is a good language to start with. I also found this YouTube video (https://www.youtube.com/watch?v=2NWeucMKrLI), and I'm downloading the compiler (https://xkcd.com/303/) (codeblocks-13.12mingw-setup.exe) from Codeblocks (http://www.codeblocks.org/downloads/26) now.

So, erm... any guides and tips for an absolute newbie? Online walkthroughs would be great. Thanks in advance!

[NichG]

For learning any programming language, its really helpful to have a project that you care about that you work on along-side the process of learning. It means that instead of just thinking 'okay, here's a bunch of stuff I have to remember', you think 'okay, here's how I can use this new thing for my project', etc.

The first few times you try to write it, you'll end up throwing away everything and starting over, but that's okay - part of the learning process. Its best if it has a fairly simple scope though, to prevent that from being too frustrating.

[factotum]

Not convinced C is the best language to learn programming in. It does not hold your hand *at all*--if you try to access an element outside the bounds of an array, or forget to free a block of memory, or dereference a pointer that hasn't been initialised yet, then C will let you do it just fine--and if you're lucky, your program will immediately crash, allowing you to figure out what you've done via a debugger. If you're *not* lucky, the program will keep running for some time afterward and then either crash or do something unexpected later on, and you then have to try and find the original problem, which can be a nightmare. The phrase "off-by-one error" will become your bane, believe me.

On the plus side, if you can figure out how to write and debug C programs, then any other language you care to turn your hand to will be easy as pie in comparison! :smallsmile:

[goto124]

Well, if C isn't the best way to start, may I ask what is?

My computer can lag a lot, so I'm afraid of stuff like programs crashing.

[factotum]

This thread has a lot of good suggestions:

http://www.giantitp.com/forums/showthread.php?398798-What-programming-language-would-you-recommend-a-newb

However, if you're afraid of programs crashing, programming might not be the best thing to be doing? It's kind of like becoming a surgeon if you're scared of the sight of blood, it's not likely to end well...

[NichG]

I think C is fine to start, but it does help to know what kind of programs you want to make. Some languages have better or easier libraries for certain things than others - its less about the languages themselves and more about where trends in programming have gone. Older libraries tend to be more convoluted to use because the design philosophy for APIs has shifted significantly over the last decade or two.

[Zyzzyva]

On the plus side, if you can figure out how to write and debug C programs, then any other language you care to turn your hand to will be easy as pie in comparison! :smallsmile:

Agda and Prolog want a word with you :smalltongue:

But yeah; the flip side is, if you don't already know programming, learning eg Python and getting the basics down and then, if necessary, discovering the "joys" of explicit pointers is a lot easier than having to deal with both learning to program and learning how to hand-manage memory.


This thread has a lot of good suggestions:

http://www.giantitp.com/forums/showthread.php?398798-What-programming-language-would-you-recommend-a-newb

However, if you're afraid of programs crashing, programming might not be the best thing to be doing? It's kind of like becoming a surgeon if you're scared of the sight of blood, it's not likely to end well...

And yeah, that thread's a good place to start looking. C is... popular, and flexible in a lot of ways, but if you're learning programming because it seems like it would be fun (as opposed to because you really really need this hand-coded runtime system working) it's probably not the best starting point. As mentioned in the thread, Python or Processing (or maybe Scratch) are pretty decent starting points.

And becoming a surgeon is a good way to get over the fear of blood. Goodness knows when my computer crashes and burns, I take it a lot more in stride than when I didn't understand it...

[BannedInSchool]

C is just assembler with fancy macros and C++ makes them even fancier! :smallwink:

[Zyzzyva]

C is just assembler with fancy macros and C++ makes them even fancier! :smallwink:

"C combines the elegance, power, and blazing speed of assembly language with the simplicity, portability, and ease-of-use of assembly language."

[ChristianSt]

If you want to learn programming in C, than that imo is a totally valid starting point. Every time someone wants a programming language for <something>, that person will get more than enough answers pointing at a whole lot of different languages.

Some programming languages might be easier to use for task X or might have a Syntax you like more, but without further knowledge a whole lot of languages are fine to start programming with. C has certainly the benefit that it has a large influence on a whole bunch of other languages and a C-style like Syntax is quite common. The imo biggest drawback (or benefit - depending on how you look at it) is that it isn't an object oriented programming language. But especially in the beginning the procedural way of thinking is a great starting point (and even if you start with a object oriented language, most tutorials will focus on procedural programming). And once you are familiar with that and want to look into object oriented programming is quite easy to pick another language that gives you that while being extremely similar to C.


And if you are afraid to crash your program, programming isn't for you. Getting errors of all sorts of kinds while programming is quite common (if you use C or any other compiled language, another common feature are "compiler errors", though with the usage of a good IDE they can mostly be figured out before actually compiling). But most often this isn't really problematic and comes with the craft. If you don't want to work with wood, carpenter will not be your dream job. :smallwink:

[Grinner]

And if you are afraid to crash your program, programming isn't for you. Getting errors of all sorts of kinds while programming is quite common (if you use C or any other compiled language, another common feature are "compiler errors", though with the usage of a good IDE they can mostly be figured out before actually compiling). But most often this isn't really problematic and comes with the craft. If you don't want to work with wood, carpenter will not be your dream job. :smallwink:

Last night, I spent probably close to three hours debugging and refactoring a program which took me about an hour to write. You will spend more time dealing with errors than you will actually writing code.

Regarding the choice of C...It would be a slog to start with C, but you would come out a much better programmer for it. Honestly, it's not as bad as some others are making it out to be, at least in the beginning. Once you begin moving into more advanced techniques, the room for error then grows exponentially.

Processing...I've never tried it, but given its visual-oriented approach, it seems like it might be a bit more intuitive to start with.

[goto124]

Erm.

Problem.

Where do I start to learn C?

Because when I googled for C, the tutorials I get... don't make sense.

I found neat guides for Python though, from the giantitp thread that's posted here.

https://wiki.python.org/moin/BeginnersGuide/NonProgrammers

http://cscircles.cemc.uwaterloo.ca/

[Grinner]

Have you looked at cprogramming.com yet?

[BannedInSchool]

Regarding the choice of C...It would be a slog to start with C, but you would come out a much better programmer for it. Honestly, it's not as bad as some others are making it out to be, at least in the beginning. Once you begin moving into more advanced techniques, the room for error then grows exponentially.
Sure, you can shoot yourself in the foot with C, but it's simple and efficient!

http://www-users.cs.york.ac.uk/susan/joke/foot.htm

Ugh, flashing back to C++ copying problems... :smalleek:

[Knaight]

Java might be a good starting point, it's fairly similar to C in a lot of ways and is commonly used in CS departments.

[Zyzzyva]

http://cscircles.cemc.uwaterloo.ca/

Hah! My alma mater wins again!

And yeah, that's a legit concern; honestly, IMHO whatever tutorial you hit first that seems good should be the language of choice.

[Flickerdart]

I was the one who suggested Processing in the previous thread, but you should also consider Javascript. IDE? Don't need it, Notepad does a fine job. Compiler? What's that - just grab literally any browser. Variable types? Never wonder why your numbers keep getting rounded, because Javascript doesn't discriminate between int and float (or for that matter string and char and all kinds of things), just call it var and move on to bigger and better things. Storing different variable types in the same array? Go ahead. Storing number and variable-indexed values within the same array? No problem. Forget a bracket or twelve? It'll still try its best to run, but everything will break and you won't know why (permissiveness has its downsides) unless you're coding in Eclipse which tells you, or check the console.

You need to learn a little bit about how HTML works because you're mostly targeting HTML elements when doing anything, but it's not a huge deal.

[Douglas]

I was the one who suggested Processing in the previous thread, but you should also consider Javascript. IDE? Don't need it, Notepad does a fine job. Compiler? What's that - just grab literally any browser. Variable types? Never wonder why your numbers keep getting rounded, because Javascript doesn't discriminate between int and float (or for that matter string and char and all kinds of things), just call it var and move on to bigger and better things. Storing different variable types in the same array? Go ahead. Storing number and variable-indexed values within the same array? No problem. Forget a bracket or twelve? It'll still try its best to run, but everything will break and you won't know why (permissiveness has its downsides) unless you're coding in Eclipse which tells you, or check the console.

You need to learn a little bit about how HTML works because you're mostly targeting HTML elements when doing anything, but it's not a huge deal.
I would advise against that. For learning programming, starting from nothing, I think it's best to go with a language that forces you to be precise and say exactly what you want in full detail. That way it gets drilled into you early and thoroughly that such things matter, and thinking about them is a good habit you want to pick up and reinforce.

Soft type definitions and ignoring sufficiently minor errors are luxuries that encourage sloppy practices if you depend on them too much, best to not have them at all until your initial habits are set.

[ChristianSt]

Soft type definitions and ignoring sufficiently minor errors are luxuries that encourage sloppy practices if you depend on them too much, best to not have them at all until your initial habits are set.

+1. While it might look tempting at a first glance, it imo makes it harder in the long run. Such features just make the debugging process more difficult.

It also doesn't hurt to learn that it is important to be precise. A typo normally causes no problem in human-to-human conversations. While programming a typo at best causes some sort of visible error and at worst is a bug you try to find for hours.

[BannedInSchool]

It also doesn't hurt to learn that it is important to be precise. A typo normally causes no problem in human-to-human conversations. While programming a typo at best causes some sort of visible error and at worst is a bug you try to find for hours.

if ( n = 0 )
{
:smallbiggrin:

[Zyzzyva]

I would advise against that. For learning programming, starting from nothing, I think it's best to go with a language that forces you to be precise and say exactly what you want in full detail. That way it gets drilled into you early and thoroughly that such things matter, and thinking about them is a good habit you want to pick up and reinforce.

Soft type definitions and ignoring sufficiently minor errors are luxuries that encourage sloppy practices if you depend on them too much, best to not have them at all until your initial habits are set.

Seconded.

Case in point:


if ( n = 0 )
{
:smallbiggrin:


type mismatch; found : Unit required: Boolean

:smalltongue:

[factotum]

Except C wouldn't report any sort of error in that situation. The code as written would assign the value 0 to n, then the IF would always resolve to FALSE because its content is zero, which is the marker for false in C. If what you were *actually* intending to do is compare n to 0, then you'd use if (n == 0) (or possibly if (!n)).

[Douglas]

Except C wouldn't report any sort of error in that situation. The code as written would assign the value 0 to n, then the IF would always resolve to FALSE because its content is zero, which is the marker for false in C. If what you were *actually* intending to do is compare n to 0, then you'd use if (n == 0) (or possibly if (!n)).
I'm fairly sure most compilers will at least issue a warning for putting an assignment in a condition like that.

Speaking of warnings: It is possible to ignore compile warnings and run your program anyway, unlike with compile errors. In many cases your program will even run correctly despite the warning. Do not make a habit of this. Compiler warnings are there for a reason, when you see one your reaction should be to learn what that reason is and fix the warning if at all possible. If you determine that the reason for the warning really truly does not apply in your particular case and that fixing the warning would be difficult, then look up and add the appropriate "ignore this warning" compiler directive to the source code along with a comment explaining why you are ignoring that warning. When you do this (which should be rare), place the warning suppression at the smallest possible scope.

[factotum]

I'm fairly sure most compilers will at least issue a warning for putting an assignment in a condition like that.

They didn't back when I did C programming for a living, although I acknowledge that was 15 years ago and the state of the art may have moved on somewhat since! :smallsmile:

[BannedInSchool]

They didn't back when I did C programming for a living, although I acknowledge that was 15 years ago and the state of the art may have moved on somewhat since! :smallsmile:
Of course originally C didn't have type checking. Just push those values on the stack and call that function. Let's see what happens, yeehaw!!! :smallbiggrin:

[NichG]

A lack of error checking just trains you to write perfect, error-free code the first time, every time!

[ChristianSt]

I'm fairly sure most compilers will at least issue a warning for putting an assignment in a condition like that.

Speaking of warnings: It is possible to ignore compile warnings and run your program anyway, unlike with compile errors. In many cases your program will even run correctly despite the warning. Do not make a habit of this. Compiler warnings are there for a reason, when you see one your reaction should be to learn what that reason is and fix the warning if at all possible. If you determine that the reason for the warning really truly does not apply in your particular case and that fixing the warning would be difficult, then look up and add the appropriate "ignore this warning" compiler directive to the source code along with a comment explaining why you are ignoring that warning. When you do this (which should be rare), place the warning suppression at the smallest possible scope.

I think the first thing one should start a tutorial with is to turn on "-Wall -Werror" or "use strict" (or whatever similar thing is available in the language your looking at).

It makes catching things that are quite likely mistakes (like the above assignment during the if) to actual errors that stop you from compiling, forcing you to make it correct (or, as Douglas mentioned, to make a annotation that says that you are sure it isn't a mistake). That is another important lesson while programming: Only because the code is legal and is running, it doesn't necessarily does what you think it does.

[BannedInSchool]

A lack of error checking just trains you to write perfect, error-free code the first time, every time!

Automatic garbage collection is for the lazy and stupid!

Ah, isn't it SmallTalk where the lack of compile-time type checking is considered an OO feature? Just send any message to any object and let it get sorted out at runtime in the OO ideal.

[Flickerdart]

That is another important lesson while programming: Only because the code is legal and is running, it doesn't necessarily does what you think it does.
Sometimes the code does what you think it does...and then you read it, and there's no way it should be doing that. That's when you leave comments to the effect of /* DO NOT EDIT BECAUSE IT BREAKS EVERYTHING */ and look for a new job.

Speaking of which, commenting your code is very important regardless of what you're writing it in. It doesn't seem important when your program is 12 lines long, but when those 12 lines are part of a 500-line script and you have to come back to them 3 months down the road after you've forgotten everything you did, those comments save a lot of time.

[Zyzzyva]

Automatic garbage collection is for the lazy and stupid!

Ah, isn't it SmallTalk where the lack of compile-time type checking is considered an OO feature? Just send any message to any object and let it get sorted out at runtime in the OO ideal.

Smalltalk is hardcore; I'm not sure if that's a good or bad thing, in this case.

[Telok]

I always worry when something I've written compiles without errors on the first try.

It's not an issue for a "hello world" type program, but once I'm up to a few objects, some file i/o, and a recursive loop or two... I know I make mistakes, I expect it. When I compile five hundred lines of code for the first time and the compiler just gives me "ok" then I start to worry.

[Zyzzyva]

I always worry when something I've written compiles without errors on the first try.

It's not an issue for a "hello world" type program, but once I'm up to a few objects, some file i/o, and a recursive loop or two... I know I make mistakes, I expect it. When I compile five hundred lines of code for the first time and the compiler just gives me "ok" then I start to worry.

You, my friend, need a more restrictive typing discipline!

[Douglas]

Speaking of which, commenting your code is very important regardless of what you're writing it in. It doesn't seem important when your program is 12 lines long, but when those 12 lines are part of a 500-line script and you have to come back to them 3 months down the road after you've forgotten everything you did, those comments save a lot of time.
Ah yes, commenting, a subject of many endless debates. There are people who advocate commenting absolutely everything, there are people who say code should be "self documenting" with no comments, and a wide range in between.

My opinions and principles on commenting:

Anyone who's going to get some use out of your comment is going to be a programmer. Assume the comment's reader can read and understand program source code, and don't waste your time duplicating the code's logic in your comments. A comment that says "store the value 10 in the variable x" is worse than useless.
Even before adding comments, your code should be easy to understand, at least on a step by step level. Names of variables, functions, classes, etc., should all be short descriptions of themselves. Instead of "x", use something like "remainingBalance". But keep them short. The point of a good name is to get across a conceptual definition of what it represents, and do so in a very short and concise manner. If you find your names are resembling whole phrases or even sentences, step back and rethink a bit. Assume the reader is already aware of the context, in a general way at least, and consider what the shortest term is that gets the idea across in that context.
If you do the previous point properly, you will find that comments would be superfluous in most - but not all - of your code. The points that remain, where comments are appropriate, are where what you are doing might be clear but not why, or where a section of code is the detailed breakdown of a concept that can be conveyed in human speech much more concisely. Add comments to explain non-obvious reasons why you are doing something, or to explain "this 20 line block of code does <one-line summary>".
Concise explanations of large blocks of code are especially common and appropriate on function and class definitions, where the name is a 2 or 3 word summary and the comment goes into more depth. In particular, these comments are often read by someone who wants to use your code but not read or modify it. Treat these comments as explaining the external characteristics of your code - "here's how to use the black box that you can't or don't want to look inside".

[Zyzzyva]

My opinions and principles on commenting:

I agree completely on all of those except the last one - in my experience the absolutely most likely person to be picking through your code is yourself or your replacement, looking to fix the bugs in it. (Of course, I work for a company that builds commission proprietary code, so it's kinda a different field than building public libraries or APIs or the like.)

[Douglas]

I agree completely on all of those except the last one - in my experience the absolutely most likely person to be picking through your code is yourself or your replacement, looking to fix the bugs in it. (Of course, I work for a company that builds commission proprietary code, so it's kinda a different field than building public libraries or APIs or the like.)
In the case of your future self or replacement looking through to fix bugs, the type of comment I described is still the best to have for that position in the code - it explains what the behavior is supposed to be, and the vast majority of bugs are going to be places where the code unintentionally does not match that. Having a comment that explains to other people what's supposed to happen when they call this code gives you a basis for comparison to analyze and check whether the code actually does do that.

If you're talking about someone puzzling over what the hell some ridiculously complex piece of code does, the confusing part is probably smaller than a whole function or class, and the comment explaining it should be right there at the confusing part. And if you have code that confusing in the first place, that's a sign of poor quality and you should try to rewrite it to be less confusing.

To quote some guy I don't remember: There are two types of code. Code that obviously has no errors, and code that has no obvious errors.

[Zyzzyva]

To quote some guy I don't remember: There are two types of code. Code that obviously has no errors, and code that has no obvious errors.

Wirth, I think.

Again, not really disagreeing with you; I write a lot of javadoc comments. My non-documentation comments almost always tend to be around ugly business logic or code dealing with bad library corner cases.

[the_druid_droid]

They didn't back when I did C programming for a living, although I acknowledge that was 15 years ago and the state of the art may have moved on somewhat since! :smallsmile:


I think the first thing one should start a tutorial with is to turn on "-Wall -Werror" or "use strict" (or whatever similar thing is available in the language your looking at).

Yeah, so far as I'm aware, most modern C/C++ compilers will catch the if (x = val) thing so long as you use -Wall (source: I've run into this error both ways, and one is really much easier to fix >.>).

I only wish I had learned to use -Wall consistently earlier in my career.

[factotum]

Sometimes the code does what you think it does...and then you read it, and there's no way it should be doing that.

The fun part is when you run into a bug in the compiler. I remember trying to figure out why a fairly simple loop I'd written was running so slow, and eventually, in desperation, I told the compiler to output the assembly code it was producing for that function. The assembly code ran to about 3K! I made the tiniest change to the loop--can't even remember what it was now, maybe changing an equal to a not equal and switching an IF statement around accordingly--and the output assembly code now came to about 100 bytes and ran like lightning.

[Douglas]

Again, not really disagreeing with you; I write a lot of javadoc comments. My non-documentation comments almost always tend to be around ugly business logic or code dealing with bad library corner cases.
Yeah, those sound like good places for comments.

Ah yes, library corner cases and bugs. One I encountered recently in Java: did you know that the Hibernate library broke the equals contract? Get a Session object from Hibernate, let's call it S, and S.equals(S) will return false. This annoyed me when I was writing unit testing code to verify that the Sessions returned from two separate calls were the same.

[Zyzzyva]

Yeah, those sound like good places for comments.

Ah yes, library corner cases and bugs. One I encountered recently in Java: did you know that the Hibernate library broke the equals contract? Get a Session object from Hibernate, let's call it S, and S.equals(S) will return false. This annoyed me when I was writing unit testing code to verify that the Sessions returned from two separate calls were the same.

Well, that's a thing. :smalleek:

[BannedInSchool]

I'm recalling a bit from Rick Cook's Wizardry series with a team attempting to bring up to standard a one-man, uncommented, massive hack and kludge all-nighter mess of code. I like the joke of the function named "cornedbeef", but not that someone couldn't identify it as a hash function just from the code. When asked of the significance of the one constant, the original author said it was just the biggest prime number he could think of. When asked if he was sure it was prime he replied, "Well, it worked". :smallbiggrin:

[Amidus Drexel]

Except C wouldn't report any sort of error in that situation. The code as written would assign the value 0 to n, then the IF would always resolve to FALSE because its content is zero, which is the marker for false in C. If what you were *actually* intending to do is compare n to 0, then you'd use if (n == 0) (or possibly if (!n)).

I dunno, I rather like being able to do that. I will admit that it's the sort of thing you can do intelligently to save space, or can do poorly and confuse the hell out of anyone else reading your code, though.

But that's me, and I've been told I have strange taste in a great many things. :smalltongue:


Yeah, so far as I'm aware, most modern C/C++ compilers will catch the if (x = val) thing so long as you use -Wall (source: I've run into this error both ways, and one is really much easier to fix >.>).

I only wish I had learned to use -Wall consistently earlier in my career.

Mine doesn't! :smallbiggrin:

Granted, it's the free version of microchip's C compiler, so there's quite a lot of things it doesn't do (any reasonable amount of assembly optimization, for one). The only warnings I've ever seen it generate were when I (mistakenly) was casting a pointer to a character variable (instead of assigning what it pointed to like I should've been doing), presumably because the conversion would've lost several bytes of data. At least it finds errors.

--
In answer to the OP's question, though - I wouldn't suggest starting with C (the best place to start is with x86 assembly, obviously). It's a pretty bare-bones language, and it's also really easy to shoot yourself in the foot. I've heard python is good for beginners (due to its simplicity), but if you want a language that's a little lower-level than that, I'd go with C++, C#, or Java. They all have a relatively C-like syntax (which seemed like what you were looking for), and all will give you the opportunity to learn and practice object-oriented programming. Go with C++ if you think pointers and manually managing dynamic memory sound like fun - if not, you'll probably want Java. I don't have a lot of experience with C#, but from what little I do know it's fairly similar to Java.

Now, if you ignore our collective advice and start with C anyway, I anticipate you becoming very good at debugging, or very frustrated. Or both. :smallamused:

[Zyzzyva]

(the best place to start is with x86 assembly, obviously)

Does anyone here actually know assembly? What's a good place to start, if you want to get a feel for assembler without necessarily learning it to the point of utility (or learning a specific assembler that would be useful in day-to-day life)?

[NichG]

It's been a long time since I had to do anything with assembly. Honestly, the only thing I ever used it for was some video mode manipulation back in DOS days. "mov ax, 13h" type stuff.

[factotum]

Many C compilers allow you to insert in-line assembly language sections in your program--I would recommend that rather than trying to write entire programs from scratch in assembly language. That way you can reserve the assembly language for those parts of the code that really *do* need to be lighting fast, and which the compiler is not doing a good enough job for your taste.

[BannedInSchool]

I had a course writing assembler to burn EPROMs for a toy device with a 8086 and LEDs and a speaker and so forth, so no OS to worry about.

Edit: But I do think it's useful to know what's going on under the hood of your lower-level programming languages like C because it explains the how and why of them.

[Zyzzyva]

I had a course writing assembler to burn EPROMs for a toy device with a 8086 and LEDs and a speaker and so forth, so no OS to worry about.

Edit: But I do think it's useful to know what's going on under the hood of your lower-level programming languages like C because it explains the how and why of them.

Well, I mean, I've worked through this (http://mitpress.mit.edu/books/elements-computing-systems), so it's not like I don't understand the "what" of assemblers. It's more like I want to know what a real, modern day assembler looks like. (The one in the book has a register! And a whole three different opcodes!)

[Grinner]

Does anyone here actually know assembly? What's a good place to start, if you want to get a feel for assembler without necessarily learning it to the point of utility (or learning a specific assembler that would be useful in day-to-day life)?

If anyone knows of any good resources on the subject (preferably online and free), I too would like to know.

[Amidus Drexel]

Well, I mean, I've worked through this (http://mitpress.mit.edu/books/elements-computing-systems), so it's not like I don't understand the "what" of assemblers. It's more like I want to know what a real, modern day assembler looks like. (The one in the book has a register! And a whole three different opcodes!)


If anyone knows of any good resources on the subject (preferably online and free), I too would like to know.

Well, Intel's got a tutorial/introduction (https://software.intel.com/en-us/articles/introduction-to-x64-assembly)online for their architecture, though I'm told x86 is an absolute nightmare to do any serious assembly coding in. I believe I've come across a similar page for MIPS before as well, but it's been a while. Google whatever architecture you want to learn; most have a tutorial of some sort available.

[Grinner]

Google whatever architecture you want to learn; most have a tutorial of some sort available.

That's another thing. If I implement some inline assembly using the Intel syntax (or whatever it's called), will the code need to be reimplemented for AMD processors? Or is there no specification on the matter and does every compiler handle it differently?

[factotum]

If you're talking an AMD processor that lives in a PC then no, you don't need to re-code--both Intel and AMD mainstream CPUs use the x86 instruction set. In fact, the 64-bit instruction set you find on modern Intel CPUs is actually an AMD invention in the first place--Intel wanted the x86 architecture to die in a fire so they bet their money on a completely new 64-bit instruction set and produced the Itanium, which proceeded to bomb in absolutely spectacular fashion. Meanwhile, AMD released 64-bit extensions to x86 in their own processors which Intel licensed back from them once they saw the way the wind was blowing.

As for x86 architecture being a bit of a nightmare, the main issue there used to be segmentation (in particular, the brain-dead way Intel implemented it)--however, on any modern OS you can pretty much forget that segmentation exists; if you allocate a 500Mb block of memory in Windows you can step through it using a 32-bit pointer without ever hitting a segment boundary. (In fact, you were able to do that in Windows 3.1 despite it being a 16-bit OS--used that a few times to speed up my code!).

[BannedInSchool]

It's more like I want to know what a real, modern day assembler looks like. (The one in the book has a register! And a whole three different opcodes!)
Registers and operations are features of the architecture, not the assembler. The lab I used for my assembly course still used DOS, but then the target was an 8086. That x64 introduction is still basically what I was doing then with just the "legacy" registers. (Aww, who's a cute BP? You are! Yes, you are!)

That's another thing. If I implement some inline assembly using the Intel syntax (or whatever it's called), will the code need to be reimplemented for AMD processors? Or is there no specification on the matter and does every compiler handle it differently?
As that introduction also mentions, you could generate incompatible AMD- or Intel-only 64-bit instructions with an assembler, but then also use only the "x64" intersection for portable output. Assembler is pretty directly generating the machine code instructions the CPU is going to execute, and the reason the two different CPUs are "compatible" is that if you feed them the same executable they do (mostly) the same thing. I suppose if you really needed to exploit clock cycles then you'd need to make incompatible assembly code for each target. Heh, haven't thought about the table showing how many cycles each instruction takes in forever either. :smallsmile:

[hajo]

Does anyone here actually know assembly?
What's a good place to start, if you want to get a feel for assembler ?

RosettaCode is a project (*) to show and compare many programming-languages.
It has a wiki with a lot of different languages (http://rosettacode.org/wiki/Category:Programming_Languages) (including assembly (http://rosettacode.org/wiki/Category:Assembly)),
and lots of problems/tasks (http://rosettacode.org/wiki/Category:Programming_Tasks) done(**) in different languages(***).

For example, "HelloWorld (http://rosettacode.org/wiki/Hello_world/Text)", "FizzBuzz (http://rosettacode.org/wiki/FizzBuzz)" or the "Sieve of Eratosthenes (http://rosettacode.org/wiki/Sieve_of_Eratosthenes)" to find prime numbers.

The page about the "Beer-song (http://rosettacode.org/wiki/99_Bottles_of_Beer)" has its own sub-page for assembly (http://rosettacode.org/wiki/99_Bottles_of_Beer/Assembly).

Also, at least these whole operatingsystems (including GUI and some apps)
have been written completely in assembly: KolibriOS (http://kolibrios.org/en/) (a fork of MenuetOS (http://menuetos.net/)).


It is driven by volonteers, much like Wikipedia.


That means, some languages have better coverage (http://rosettacode.org/wiki/Rosetta_Code/Rank_languages_by_popularity) then others.


See also this much shorter list of "really simple (http://rosettacode.org/wiki/Simple)" tasks.


If you want "to get a feel for assembler" for yourself:
Assembly is programming near the "bare metal",
with a very limited set of instructions,
and each operation doing only a tiny bit of work.

To get into the mindset (without need to actually learning assembly),
try one of the simple "fun" languages, like BF* (http://rosettacode.org/wiki/Category:Brainf***) (it doesn't get much simpler),
Befunge (http://rosettacode.org/wiki/Befunge) or SNUSP (http://rosettacode.org/wiki/Category:SNUSP), understand some examples (like HelloWorld, FizzBuzz etc.),
then try to modify them, and write some new program for yourself.

Some online-compilers (http://ideone.com/) have support for BF*,
no need to install something on your machine :smallbiggrin: