Could you compile a program manually?
-
Oh, I see... You're new here... Take this sage advice in the spirit in which it's given - don't be a dork.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997 -
Brandon T. H. wrote:
Is there some way to process a source-to-executable like a computer by hand?
Yes (well duh, computers can't compute anything that humans can't, they're just faster at it), and it's not even that hard (just time-consuming). Converting whatever-language source to assembly? Piece of cake. Assembling by hand? Conceptually simple, only requires looking things up in a table. Putting it in the right executable format? Ok that one is a little tricky to get right, but also not that hard.
Brandon T. H. wrote:
If so, could you point to some documents?
Sure. For x86+windows: Intel manuals[^] ModRM encoding (on sandpile.org)[^] PE 101[^]
Brandon T. H. wrote:
Could you also compile a device driver source to ".sys" or ".vxd"
I see no reason why this should be impossible.
-
Yes, you just need to convert each line of source code into its object code equivalent. Once you have done that you build it into a binary file with a hex editor and, hey presto, Robert's your mother's brother.
One of these days I'm going to think of a really clever signature.
-
When I look at some of the pie-in-the-sky news items about things like automatic parallelization, I get the sense that we are alarmingly close to the day when an animated character in an IDE says things like "it looks like you're trying to write an OS." I think this kind of thing is an example of what I call the "Hero Anti-Pattern," in which one supposedly brilliant developer abstracts everything (garbage collection, parallelization, "plumbing" code...) away from the rest of us. My gut tells me that self-proclaimed geniuses toiling away in a vacuum will probably never really keep the rest of us from having to worry about whatever it is they're trying to fix. Instead, what results is that these people get to shape the future of development, and rake in the concomitant glory and cash, while the rest of us just end up doing the same tasks (albeit in Hero-ized form).
Aren't we already almost there? VS: "File/New/ASP.NET MVC Project" or "File/New/Entity Model." Eclipse: "File/New/Java Package" Most modern IDE's abstract away so much boiler plate code that we have acheived almost the equivalent of Clippy already. Newcomers, such as myself, begin to believe that that's all there is to it. The "run" button, which in reality "builds" such projects then executes the build result, optionally stepping through in an integrated debugger, removes a whole lot behind-the-scenes operations. While all of these are great for productivity, and in many cases represent the ultimate goal of code re-use, they also deprive (for a time, anyway) us of the need to learn how these hidden parts of the process work.
-
Oh, I see... You're new here... Take this sage advice in the spirit in which it's given - don't be a dork.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997Sage advice... Pssh. Ya junior code snot. I'm glad I'm not the only assembler dork out there. This is the sort of question asked by people who end up designing the compilers you all use.
-
Ah, the memories! First did this when my computer had a 16 bit address bus and 8 bit op-codes and a total of 4K of RAM. Then I discovered there was something called a "compiler" and haven't had the urge to engage in this kind of masochism since.
-
Is there some way to process a source-to-executable like a computer by hand? If so, could you point to some documents? Could you also compile a device driver source to ".sys" or ".vxd" (depending whether you are developing for a non-NT or NT Windows operating system)?
Simple Thanks and Regards, Brandon T. H. Programming in C and C++ now, now developing applications, services and drivers (and maybe some kernel modules...psst kernel-mode drivers...psst). Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison
I used to do this all the time in my mainframe days. Operating systems used to be written in assembler, and the only way to correct bugs or add extensions on the fly was to hand-assemble the code into pure machine code. One system I supported for a number of years had an on-line patcher so you could patch the O/S while the system was up and running. I used to give the operations staff hairy fits when I did this ;) Just to show how big some leaps can be -- I went from an all-assembler O/S to a machine whose O/S was written in PL/1. An interesting leap indeed, especially since the source code of the PL/1 O/S was all on-line, so you could use parts of it in your own applications.
-
Is there some way to process a source-to-executable like a computer by hand? If so, could you point to some documents? Could you also compile a device driver source to ".sys" or ".vxd" (depending whether you are developing for a non-NT or NT Windows operating system)?
Simple Thanks and Regards, Brandon T. H. Programming in C and C++ now, now developing applications, services and drivers (and maybe some kernel modules...psst kernel-mode drivers...psst). Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison
Many years ago, while teaching at a local college and working as an architect for a new database system, I decided to write the compiler I was requiring my students to write. At that time, I was considered a good assembler programmer. I decided to compare the output of the compiler I wrote with my own hand-coded assembly. As I recall, my assembly contained about 15 instructions; the compiler's generated assembly code contained 8 instructions. I learned a valuable lesson.
Gus Gustafson
-
Is there some way to process a source-to-executable like a computer by hand? If so, could you point to some documents? Could you also compile a device driver source to ".sys" or ".vxd" (depending whether you are developing for a non-NT or NT Windows operating system)?
Simple Thanks and Regards, Brandon T. H. Programming in C and C++ now, now developing applications, services and drivers (and maybe some kernel modules...psst kernel-mode drivers...psst). Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison
Of course you can. The act of compiling is simply a translation between the chacters you typed into a file and the sequence of binary bytes that need to get fed to the CPU for execution. The .sys or .vxd is merely a file format. All are documented. As for pointers to documents? Sorry, can't help you there.. I haven't cared about such documents for more than 20 years. Translating something like C++ to assembly is tedious at best. It would be quicker to do what the compiler cannot do -- take your knowledge of the desired behavior of the program, and write an assembly progam directly to accomplish the same task. Translating assembly to binary object code is a very simple per-instruction translation (well, it used to be.. but its a bit more complex now). The question is why? Why do you want to do that? If it is just to learn the process, its easier to take a compiler course as it'll start from basic concepts, evolving them into running code. It will be a lot easier to understand how a compiler works coming at it that way than trying to start with the 1s and 0s. You'll get lots of practice walking through all the steps of compilation along the way. Assembly is too easy to justify a course -- just grab an assembly manual for your processor of choice and read through it.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
Is there some way to process a source-to-executable like a computer by hand? If so, could you point to some documents? Could you also compile a device driver source to ".sys" or ".vxd" (depending whether you are developing for a non-NT or NT Windows operating system)?
Simple Thanks and Regards, Brandon T. H. Programming in C and C++ now, now developing applications, services and drivers (and maybe some kernel modules...psst kernel-mode drivers...psst). Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison
When I was in high school I used to hand assemble a lot of programs. We only had access to the computers during school hours. In Print Shop, I created forms to write the source code on and left myself a column to write the opcodes into as well. But then I was programming DEC PDP-8's and they used 12 bit words with the first octal digit being the opcode, the rest being addressing. The operate commands were a bit trickier, but there was a rhyme and reason for most the bit settings, the rest you memorized. Used to do the same for multi-byte 6502, but today's 80x86 (if that still the term) multi-byte commands would be much, much harder.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
-
When I look at some of the pie-in-the-sky news items about things like automatic parallelization, I get the sense that we are alarmingly close to the day when an animated character in an IDE says things like "it looks like you're trying to write an OS." I think this kind of thing is an example of what I call the "Hero Anti-Pattern," in which one supposedly brilliant developer abstracts everything (garbage collection, parallelization, "plumbing" code...) away from the rest of us. My gut tells me that self-proclaimed geniuses toiling away in a vacuum will probably never really keep the rest of us from having to worry about whatever it is they're trying to fix. Instead, what results is that these people get to shape the future of development, and rake in the concomitant glory and cash, while the rest of us just end up doing the same tasks (albeit in Hero-ized form).
The end result of this abstraction cycle is an AI developer. You speak into the microphone, "Siri, write me an Accounts Receivable program." 'She' answers, "OK. How many accounts will you want to manage?" If anyone reading this post isn't frightened about the future of their career, or of the human race for that matter, you aren't paying attention. I'm glad I'm not just starting out my career.
-
The end result of this abstraction cycle is an AI developer. You speak into the microphone, "Siri, write me an Accounts Receivable program." 'She' answers, "OK. How many accounts will you want to manage?" If anyone reading this post isn't frightened about the future of their career, or of the human race for that matter, you aren't paying attention. I'm glad I'm not just starting out my career.
There will always be a job for software people. That program written by the AI? The AI is no more able to solve the Halting Problem than you are. It cannot foresee the entire range of possible problems and world interactions. So that accounts package it just wrote will need to be fixed when it has mysteriously slow performance on your new SSD storage. It might crash on the first Tuesday after a leap second. Things will need to be fixed when the database and the web frontend disagree on the proper UTF-8 encoding. And it'll probably only work correctly when you use all Microsoft, Google or Apple products of the newest revision. God help the office that has a mixture or has to support old Windows XP desktops! I foresee AI programming making the easy things really easy, leaving us to solve the difficult problems. As an example, CPU design software has made a lot of what designers used to obsolete. But it hasn't resulted in fewer engineers: they just spend their time designing even larger and more complicated chips.
-
Is there some way to process a source-to-executable like a computer by hand? If so, could you point to some documents? Could you also compile a device driver source to ".sys" or ".vxd" (depending whether you are developing for a non-NT or NT Windows operating system)?
Simple Thanks and Regards, Brandon T. H. Programming in C and C++ now, now developing applications, services and drivers (and maybe some kernel modules...psst kernel-mode drivers...psst). Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison
Yes, I suppose you could but it's not cost-effective. That's what compilers and assemblers are for. I've done it but only for very small sections of assembly code, never a high-level language. One case was where I had the binary firmware and the source code but no assembler and I had to do a patch to fix a timing problem.
-
There will always be a job for software people. That program written by the AI? The AI is no more able to solve the Halting Problem than you are. It cannot foresee the entire range of possible problems and world interactions. So that accounts package it just wrote will need to be fixed when it has mysteriously slow performance on your new SSD storage. It might crash on the first Tuesday after a leap second. Things will need to be fixed when the database and the web frontend disagree on the proper UTF-8 encoding. And it'll probably only work correctly when you use all Microsoft, Google or Apple products of the newest revision. God help the office that has a mixture or has to support old Windows XP desktops! I foresee AI programming making the easy things really easy, leaving us to solve the difficult problems. As an example, CPU design software has made a lot of what designers used to obsolete. But it hasn't resulted in fewer engineers: they just spend their time designing even larger and more complicated chips.
Zan Lynx wrote:
There will always be a job for software people. The AI is no more able to solve the Halting Problem than you are.
Once the AI is approximately as capable as a developer, it can fix its own bugs, which of course are unstated requirements as far as the machine is concerned. Just like with human developers, the fix may introduce new problems. Just like with human developers, the quality of the code may be high or low. The AI can also tinker with its own code. In the end game, an AI can replace us; first poorly, later better, finally completely. Remind me again why anyone with sense would work on such a program. It may seem ok when the goal is far away. I hope we wise up.
-
Brandon T. H. wrote:
Is there some way to process a source-to-executable like a computer by hand?
Yes (well duh, computers can't compute anything that humans can't, they're just faster at it), and it's not even that hard (just time-consuming). Converting whatever-language source to assembly? Piece of cake. Assembling by hand? Conceptually simple, only requires looking things up in a table. Putting it in the right executable format? Ok that one is a little tricky to get right, but also not that hard.
Brandon T. H. wrote:
If so, could you point to some documents?
Sure. For x86+windows: Intel manuals[^] ModRM encoding (on sandpile.org)[^] PE 101[^]
Brandon T. H. wrote:
Could you also compile a device driver source to ".sys" or ".vxd"
I see no reason why this should be impossible.
Thank you. :cool:
Simple Thanks and Regards, Brandon T. H. Programming in C and C++ now, now developing applications, services and drivers (and maybe some kernel modules...psst kernel-mode drivers...psst). Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison
-
remember me to get you a 5 when the vote system gets back online, you deserve it.
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
Sentenryu wrote:
when the vote system gets back online
What happened to that thing anyways :~, even though this has nothing to do with compiling by hand. It's been a while.
Simple Thanks and Regards, Brandon T. H. Programming in C and C++ now, now developing applications, services and drivers (and maybe some kernel modules...psst kernel-mode drivers...psst). Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison
-
Yes, you just need to convert each line of source code into its object code equivalent. Once you have done that you build it into a binary file with a hex editor and, hey presto, Robert's your mother's brother.
One of these days I'm going to think of a really clever signature.
Thanks man.
Simple Thanks and Regards, Brandon T. H. Programming in C and C++ now, now developing applications, services and drivers (and maybe some kernel modules...psst kernel-mode drivers...psst). Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison
-
Sage advice... Pssh. Ya junior code snot. I'm glad I'm not the only assembler dork out there. This is the sort of question asked by people who end up designing the compilers you all use.
My man, haha.
Simple Thanks and Regards, Brandon T. H. Programming in C and C++ now, now developing applications, services and drivers (and maybe some kernel modules...psst kernel-mode drivers...psst). Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison
-
Sage advice... Pssh. Ya junior code snot. I'm glad I'm not the only assembler dork out there. This is the sort of question asked by people who end up designing the compilers you all use.
My man, ha ha.
Simple Thanks and Regards, Brandon T. H. Programming in C and C++ now, now developing applications, services and drivers (and maybe some kernel modules...psst kernel-mode drivers...psst). Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison