Advice on bottom up approach.
Author |
Message |
Kumpel
|
Posted: Tue Aug 04, 2009 10:58 pm Post subject: Advice on bottom up approach. |
|
|
Hello all, new to the forum, seeking advice.
I recently tried learning c++ with the goal of learning to program, if anyone is interested I used Accelerated c++(wonderfully written by the way). I soon realized that I desired to know exactly how the memory addresses and the processor worked, on bit level. It frustrated me a great deal to have to take for granted concepts that were put forth, knowing that they had full explanations on the machine level. So after a brief period of insanity consisting of me going over the terminology, consulting different books to gain a complete understanding, I realized that c++ was not the approach I should take if I wanted to learn more than just programming.
I now realize that my interest lies within computer science instead of software engineering.
I am tempted to try learning assembly language, but most of the books are focused around the 86 architecture, and seem to be more about programming and it's application, rather than theory or raw description. My interest is primarily concerned with how and I do not care about the potential application of what I'm learning beyond attaining a more complete knowledge.
I will hazard to give a more exact description of what I want to learn, but would ask not to take it too seriously as I'm unaware of all thats out there. I would like to know how the processor does int a = 5. Where exactly on the processor it happens, how it happens. I would like it to be explained without any level of abstraction(well... beyond quantum mechanics ), while still being made aware of the levels of abstraction commonly used (this last part is not required, merely an advantage). I first became interested in this level of detail when browsing kernal descriptions and operating system books(the one on the BeOS filesystem really interested me). I would like to be able to pick up the following books and be able to understand them, Structure and Interpretation of Computer Programs, Art of Computer Progamming, Accelerated C++, any number of books on computational theory, books on operating systems, data structures, algorithm analysis, basically most areas ranging from circuit design to programming.
If I had to pursue computer science further, on my own, I would procede to trying to understand assembly language and pick up a book on the 86 architecture. I would also review the material needed to understand calculus and proceed with learning calculus, as I don't see myself getting by much longer with the amount of math I currently know.
The following paragraph serves only to give a description of my current state and as a potential ward against wasted advice.
I am not attending a facility for higher education and do not have the interest or desire to do so. The method of learning I wish to pursue is through books, coupled with an occasional video/audio lecture to mill over, in addition to library access and online forums. I do not desire to initially engage new material through either lecture or analogy, the latter of which I assume I will not have to worry much about in computer science.
I ask, what material do you think I should approach, and might you have a suggestion for a book, and possible explanation for the choice. I leave this post unadultered for fear of brevity. Likewise I do not expect to get an answer to my exact specifications, and anticipate a few follow up posts to help me clear up what exactly it is I want. Basically I'm using this forum to escape additional research, and I acknowledge this laziness. |
|
|
|
|
![](images/spacer.gif) |
Sponsor Sponsor
![Sponsor Sponsor](templates/subSilver/images/ranks/stars_rank5.gif)
|
|
![](images/spacer.gif) |
jbking
|
Posted: Wed Aug 05, 2009 9:24 am Post subject: Re: Advice on bottom up approach. |
|
|
I think the "int a = 5" interpretation is best answered by looking at compilers for where to go next. While I believe the simple answer is that in the stack there is memory allocated for an integer that is given an initial value where only the 1 and 4-bits are on, that may not be as low level as you'd like. Perhaps you'd want to know what is that stack and how does it work and so forth. "Principles of Compiler Design" a.k.a. "The Dragon Book" would be a suggestion for a textbook to learn more about compilers.
In terms of your not liking where assembly language books focus, you may be missing how some languages were created and why do we have things like virtual machines or intermediate languages that remove some of the low level details when writing code. |
|
|
|
|
![](images/spacer.gif) |
Kumpel
|
Posted: Wed Aug 05, 2009 4:34 pm Post subject: Re: Advice on bottom up approach. |
|
|
Thank you for the added clarity. Although I would ask for one more clarification, "Perhaps you'd want to know what is that stack and how does it work and so forth.", was I correct in interpreting this as not being covered in the dragon book?
I guess I want to know how the processor instructions work. It's frustrating, but in a good way, that I continually find myself interested in the next lowest level whenever I approach a different level. I think it's safe for me to assume that the whole of computer science interests me. I was even thinking about starting from the electrical engineering perspective.
I am going to the library today, hopefully they have the dragon book so I can browse through it in depth.
I can only think that I seem far flung with my airy talk and grand assumptions about computer science, hopefully they do not prove illegitimate! |
|
|
|
|
![](images/spacer.gif) |
DemonWasp
|
Posted: Wed Aug 05, 2009 4:48 pm Post subject: RE:Advice on bottom up approach. |
|
|
You're looking towards more of a "computer engineering" perspective if you're looking for how instructions are actually interpreted and executed by the processor, how they arrive there, and the like. I wish I could recommend a good book on processor design, but I learned about it through CS251 at UW - and they didn't require a textbook, only course notes. |
|
|
|
|
![](images/spacer.gif) |
jbking
|
Posted: Wed Aug 05, 2009 5:59 pm Post subject: Re: Advice on bottom up approach. |
|
|
I think the Call Stack would be covered in the Dragon Book as this is part of how a program executes in some operating systems. |
|
|
|
|
![](images/spacer.gif) |
Kumpel
|
Posted: Wed Aug 05, 2009 8:14 pm Post subject: Re: Advice on bottom up approach. |
|
|
Upon further examination I went back to computer architecture, and the bridging point between microarchitecture and instruction set architecture really appealed to me, I feel as though I would be comfortable learning assembly language after this. It's not so much that these are the things that interest me the most, as the concepts of data structures and algorithms really appeal. I just feel as though I can understand these topics from the lowest perspective while still taking advantage of the higher abstractions.
Does this seem feasible to you? After investing myself in this research, I come away with the sense that it is doable, but I always hear "specific research fields", "narrower fields of research", "too much to know it all", yet I cannot see this. Of course some fields are larger than others, and the effort to understand them thoroughly would be substantial, but I am doubtful that it's impossible to have a near complete understanding of computers, range processor-end user. Admittedly, the need to sacrifice learning about all the different paradigms and approaches/topics in each topic is evident. |
|
|
|
|
![](images/spacer.gif) |
jbking
|
Posted: Thu Aug 06, 2009 9:23 am Post subject: Re: Advice on bottom up approach. |
|
|
I don't think it is feasible but I would still suggest trying as I could well be wrong. The lowest perspective while still taking advantages of the higher abstractions kind of makes me think of someone learning the intracacies of English by studying the alphabet to learn how paragraphs and chapters work as the smallest breakdown of English is the alphabet but it is words and sentences that form paragraphs with chapters being another construct to understand. The reason for the narrow research fields is that if someone tried to read all the latest academic papers in Computer Science as soon as they come out, it wouldn't be possible to keep up with that. I'm thinking more of how long it would take a person to read through a Ph.D. thesis and then multiply that by the number coming out each year. That is just academia as there is also another world out there outside of those walls which is where you have the latest advances by companies like Intel or Microsoft to try to keep up as they are changing the tools used whether it be in hardware or software. If you can get a look at some of the older IDEs and compare them to more recent ones you may see some of the differences but this isn't quite where you are looking yet. There is a whole realm of how to develop software and make projects work that is outside of an actual machine or code itself but that is part of the bigger picture that I know that you don't know yet.
I'm not saying you shouldn't follow what you want to do. I am saying that you have to be realistic and that you'll find various limitations as you try to get into all the things going on within the realm of computer science and programming. Have you looked into all the frameworks and tools for a given language like C# or Java? There are tons I believe and some new ones if not new versions coming every so often that tend to be interesting to see. |
|
|
|
|
![](images/spacer.gif) |
btiffin
![](http://compsci.ca/v3/uploads/user_avatars/189169540547b535e50e4a7.jpg)
|
Posted: Thu Aug 06, 2009 8:05 pm Post subject: Re: Advice on bottom up approach. |
|
|
gforth
Try a Forth system. You, an ok prompt, and the machine guts at your fingertips. Not a hand-holdin' wussy interpreter, but a he-man hairy neck and 8 broken legs kinda interpreter.
http://www.gnu.org/software/gforth/gforth.html or Bernd Paysan's page at http://www.jwdt.com/~paysan/gforth.html
code: |
$ gforth
Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
( user input)
see .
( response)
: .
s>d d. ; ok
( user input)
see dup
( response)
Code dup
( $804CB7F ) mov dword ptr 8072560 , ebx \ $89 $1D $60 $25 $7 $8
( $804CB85 ) mov eax , esi \ $89 $F0
( $804CB87 ) mov edx , dword ptr [esi] \ $8B $16
( $804CB89 ) add ebx , # 4 \ $83 $C3 $4
( $804CB8C ) lea esi , dword ptr FC [esi] \ $8D $76 $FC
( $804CB8F ) mov dword ptr FC [eax] , edx \ $89 $50 $FC
( $804CB92 ) mov edi , dword ptr FC [ebx] \ $8B $7B $FC
( $804CB95 ) mov eax , edi \ $89 $F8
( $804CB97 ) jmp eax \ $FF $E0
end-code
ok
( some more user input; throw a 9 on the stack, duplicate the top of stack, display a carriage return, display the string form of the thing on top)
9 dup cr .
( response)
9 ok
( erase 3 bytes at pad)
pad 3 erase ok
( hose the system; attempt to clear "pad" (some address) bytes starting at address 3)
3 pad erase
( response)
:14: Invalid memory address
3 pad >>>erase<<<
Backtrace:
$B79B6EA4 fill
( RATS! wussy interpreter ;)
|
As the old guy; in the good old days, see dup would have shown the much faster CODE S ) S -) MOV NEXT. No protection, no testing, just do it. ERASE would do as it was told and erase the memory starting at 3, and well, saying bye bye to the interrupt vectors on most architectures. This emasculating, protect the programmer from mistakes and resource limits stuff ... bah! But kidding aside, I'm of the opinion that Forth is one of thee best ways to learn programming, and the von Neumann model of computing.
Cheers |
|
|
|
|
![](images/spacer.gif) |
Sponsor Sponsor
![Sponsor Sponsor](templates/subSilver/images/ranks/stars_rank5.gif)
|
|
![](images/spacer.gif) |
|
|