Programming Forums > Application Development > Assembly

teencoder · Jul 29th, 2005, 12:21 PM

I mean with X64 prohibiting inline assembler is it worth it I mean isn't the only modern use of assembler to pump extra speed.
I'm currently learning a ton of C++ and stumbled upon inline assembler on the web researched and googled. And discoverd an X64 issue with inline assembler witch is turning me down. Will X86 assembly be similiar enough to X64 to make X86 assembler knowledge worth while.

DaWei · Jul 29th, 2005, 1:36 PM

Learning assembly language will give you a better idea of how the device works under the hood. It will not automatically give you the ability to wreak the utmost from the machine in terms of perfomance, as it would have in years gone by. The nature of the beast has changed with the advent of hyperthreading, dual-core, co-processing, and instruction and data cache. It takes a lot of study far beyond the mere learning of opcodes to master those things.

The machine code emitted by compilers is usually less efficient in terms of footprint and register usage than a hand coder could achieve, but the story goes far beyond that. Even compiler writers who have studied the best ways in which to achieve optimal use of the machine can be stymied by the differences between models. The correct approach to pipelining, for instance, will be dictated by the number and size of the cache segments, and that may well vary from model to model.

I realize that the younger generation considers a knowledge of assembler to be "cool". For the older generation, it was often the only game in town. I doubt that any of you can actually appreciate the fact that it was once economical for me to spend three weeks figuring out how to save SEVEN BYTES!!! :eek: That translates to a pain in the south end for a coder walking north. There is a market for the highly competent assembly coder, but it's a relatively tiny niche. If you aim for it, you better be among the best.

iignotus · Aug 3rd, 2005, 11:03 PM

You spelled 'Geeks' wrong n00b.

Welcome.

teencoder · Aug 4th, 2005, 9:24 PM

I'll look in to it. I know it will be hard accessing the processer directly. Plus to me that seven bytes makes since back then capacities were greatly smaller than that of a high density floppy. Back then lean and mean was the game now it's cool bloatware quite a shame. Can you possibly show what the hello world program would look like. Thanks.
P.S. Popularity is the last thing on my mind. I just like pushing myself to my mental limits.

OpenLoop · Aug 4th, 2005, 9:32 PM

Quote:

Originally Posted by teencoder

Back then lean and mean was the game, now it's cool bloatware quite a shame.

Hey, that rhymes. Forget programming, go to poetry. Maybe you'll become a rap star and make more than all the programmers on earth combined.
Back to your question, I think DaWei answered it pretty well. I liked assembly days, pretty fun stuff to be programming hardware and voltages if you ask me.

Gink · Aug 4th, 2005, 9:56 PM

Quote:

Originally Posted by teencoder

I'll look in to it. I know it will be hard accessing the processer directly. Plus to me that seven bytes makes since back then capacities were greatly smaller than that of a high density floppy. Back then lean and mean was the game now it's cool bloatware quite a shame. Can you possibly show what the hello world program would look like. Thanks.
P.S. Popularity is the last thing on my mind. I just like pushing myself to my mental limits.

(Toggle Plain Text)

[BITS 16]

SEGMENT cstart

..start:

mov ax,data
mov ds,ax

mov ax,stack
mov ss,ax

mov sp,stacktop

mov ax,0x0900
mov DX,HelloMsg
int 0x21

mov ax,0x4C00
int 0x21


SEGMENT stack stack
resb 64
stacktop:

SEGMENT data
HelloMsg db "Hello World!",0xD,0xA,'$'

teencoder · Aug 4th, 2005, 11:02 PM

Okay I have alot of research to do I see alot of Hex addresses. I knew this wasn't going to be easy. Then again nothing worth having comes easy.

DaWei · Aug 5th, 2005, 7:59 AM

Note that the assembly program shown presumes that you have real mode capabilities and MSDOS functions behind a software interrupt table (or an emulation thereof) that matches up with a particular BIOS. I/O is highly machine dependent no matter how you write it and OS dependent if you're trying to take advantage of existing I/O functions.

All machine values are binary. Hexadecimal allows one to express that in physically shorter numbers that provide the ability to mentally visualize the state of each bit in the pattern.

Assembly language has nothing directly to do with programming "hardware" and "voltages". Registers and memory are hardware, but they remain hardware even when you're stuffing them with the emissions of a high level language. Your program neither knows nor cares whether the processor is running at 3.3 volts, 5 volts, or lebenty-leben volts.

The simple, essential microprocessor is not hard to understand. It has at its heart an ALU (arithmetic/logic unit) with two inputs and one output. The number of bits ganged together as "one input" varies. The ALU can do a few things such as add, and, and invert. Which it does depends upon the control signals applied to it. These are provided by the "opcode" part of your instruction. The values to be operated on are provided by the "operand" part of the instruction. These may be immediate (value right in the instruction), direct, or indirect. The opcode also specifies what to do with the result.

Instructions are no different than data. They're just used differently. One indicates that they are instructions by pointing at them with the machine's instruction pointer. When the machine reads an instruction, it knows by its content how many following bytes are used as a part of THAT instruction, and consequently, where the NEXT instruction begins. Designers dink around with this organization and come up with organizational methods and approaches that determine whether or not the particular device is CISC, RISC, or whatever.

teencoder · Aug 6th, 2005, 11:05 PM

Okay so if I learned assembler I would ultimatly understand software from the ground up? And if I write in mainstream 32-bit X86 code will my code run on AMDs and Intels that use X86 alike? Any good tutorials you can recommend? If I make a big mistake will I fry my computer?

DaWei · Aug 7th, 2005, 9:39 AM

Quote:

Okay so if I learned assembler I would ultimatly understand software from the ground up?

No. No more than learning to use a pencil or a typewriter or a word processor will make you a Hemingway. You will have learned to use a tool. In doing so you will have learned something about current microprocessor architecture. You will also no doubt learn why a good, high-level language is a Valuable Thang.

Jul 29th, 2005, 12:21 PM	#1
teencoder Hobbyist Programmer Join Date: Jul 2005 Posts: 158 Rep Power: 0	Should I learn assembler? I mean with X64 prohibiting inline assembler is it worth it I mean isn't the only modern use of assembler to pump extra speed. I'm currently learning a ton of C++ and stumbled upon inline assembler on the web researched and googled. And discoverd an X64 issue with inline assembler witch is turning me down. Will X86 assembly be similiar enough to X64 to make X86 assembler knowledge worth while. __________________ Geeks may not be cool now but in the long run they prosper.

Jul 29th, 2005, 1:36 PM	#2
DaWei Resident Grouch Join Date: Jun 2005 Posts: 6,453 Rep Power: 10	Learning assembly language will give you a better idea of how the device works under the hood. It will not automatically give you the ability to wreak the utmost from the machine in terms of perfomance, as it would have in years gone by. The nature of the beast has changed with the advent of hyperthreading, dual-core, co-processing, and instruction and data cache. It takes a lot of study far beyond the mere learning of opcodes to master those things. The machine code emitted by compilers is usually less efficient in terms of footprint and register usage than a hand coder could achieve, but the story goes far beyond that. Even compiler writers who have studied the best ways in which to achieve optimal use of the machine can be stymied by the differences between models. The correct approach to pipelining, for instance, will be dictated by the number and size of the cache segments, and that may well vary from model to model. I realize that the younger generation considers a knowledge of assembler to be "cool". For the older generation, it was often the only game in town. I doubt that any of you can actually appreciate the fact that it was once economical for me to spend three weeks figuring out how to save SEVEN BYTES!!! :eek: That translates to a pain in the south end for a coder walking north. There is a market for the highly competent assembly coder, but it's a relatively tiny niche. If you aim for it, you better be among the best. __________________ Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code. Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

Aug 4th, 2005, 9:24 PM	#4
teencoder Hobbyist Programmer Join Date: Jul 2005 Posts: 158 Rep Power: 0	I'll look in to it. I know it will be hard accessing the processer directly. Plus to me that seven bytes makes since back then capacities were greatly smaller than that of a high density floppy. Back then lean and mean was the game now it's cool bloatware quite a shame. Can you possibly show what the hello world program would look like. Thanks. P.S. Popularity is the last thing on my mind. I just like pushing myself to my mental limits. __________________ Geeks may not be cool now but in the long run they prosper. Last edited by teencoder; Aug 4th, 2005 at 9:41 PM.

Aug 4th, 2005, 11:02 PM	#7
teencoder Hobbyist Programmer Join Date: Jul 2005 Posts: 158 Rep Power: 0	Okay I have alot of research to do I see alot of Hex addresses. I knew this wasn't going to be easy. Then again nothing worth having comes easy. __________________ Geeks may not be cool now but in the long run they prosper.

Aug 5th, 2005, 7:59 AM	#8
DaWei Resident Grouch Join Date: Jun 2005 Posts: 6,453 Rep Power: 10	Note that the assembly program shown presumes that you have real mode capabilities and MSDOS functions behind a software interrupt table (or an emulation thereof) that matches up with a particular BIOS. I/O is highly machine dependent no matter how you write it and OS dependent if you're trying to take advantage of existing I/O functions. All machine values are binary. Hexadecimal allows one to express that in physically shorter numbers that provide the ability to mentally visualize the state of each bit in the pattern. Assembly language has nothing directly to do with programming "hardware" and "voltages". Registers and memory are hardware, but they remain hardware even when you're stuffing them with the emissions of a high level language. Your program neither knows nor cares whether the processor is running at 3.3 volts, 5 volts, or lebenty-leben volts. The simple, essential microprocessor is not hard to understand. It has at its heart an ALU (arithmetic/logic unit) with two inputs and one output. The number of bits ganged together as "one input" varies. The ALU can do a few things such as add, and, and invert. Which it does depends upon the control signals applied to it. These are provided by the "opcode" part of your instruction. The values to be operated on are provided by the "operand" part of the instruction. These may be immediate (value right in the instruction), direct, or indirect. The opcode also specifies what to do with the result. Instructions are no different than data. They're just used differently. One indicates that they are instructions by pointing at them with the machine's instruction pointer. When the machine reads an instruction, it knows by its content how many following bytes are used as a part of THAT instruction, and consequently, where the NEXT instruction begins. Designers dink around with this organization and come up with organizational methods and approaches that determine whether or not the particular device is CISC, RISC, or whatever. __________________ Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code. Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

Aug 6th, 2005, 11:05 PM	#9
teencoder Hobbyist Programmer Join Date: Jul 2005 Posts: 158 Rep Power: 0	Okay so if I learned assembler I would ultimatly understand software from the ground up? And if I write in mainstream 32-bit X86 code will my code run on AMDs and Intels that use X86 alike? Any good tutorials you can recommend? If I make a big mistake will I fry my computer? __________________ Geeks may not be cool now but in the long run they prosper.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Programming Forums > Application Development > Assembly

Should I learn assembler?