Is assembly simple?

[serberus]

Due to the fact that assembly is very low level does that make it inherently simple?

Is it something that can be learned easily and is essentially quite basic and just requires a dictionary of sorts so you can determine what each bit of code is doing, or is it the complete opposite and is very complicated because of it's simplicity? if that makes any sense...


I am very keen on trying to get ShowEQ running again but I have no ASM experience and very limited C++ experience.

I have read http://seq.sourceforge.net/forums/showthread.php?threadid=3432&highlight=opcode this topic, which seems a great source of information, but at the moment it all means nothing to me.

On a different topic, as I understand it, currently the EQ datastream is just XOR'd and compressed? If that's not true, please correct me, if it is true, what kind of compression is being used please?

Thanks

Serberus

edit: I should mention that my current goal is to track down all the opcodes.

[BlueAdept]

Originally posted by serberus
Due to the fact that assembly is very low level does that make it inherently simple?

No, the lower the level of a language, the closer it is to machine language, the faster the programs will run. What that usually means is the lower the level, the harder the language. Most people do not write programs in assembly. Even though it is the just about the fastest code (I guess binary would be the fastest, but no one programs in binary), it would be countless lines. Usually people will program in C (or some other language) and add in a bit of assembly code to make that process run faster.

That is why Basic is very easy, but the programs you make from it are pigs.

Assembly is usually used for debugging. When you debug a program, it converts it into assembly.

Here is a link for some assembly help:

http://directory.google.com/Top/Computers/Programming/Languages/Assembly/x86/FAQs,_Help,_and_Tutorials/

[uRit1u2CBBA=]

I agree that it is very difficult. Not to mention, CPU specific. Which is why C is nice for cross-compiling over multiple platforms. The same C code will generate different assembly code based on system specific information.

One good example that a teacher gave me on the first day of an assembly class I took.

If life were in C, you would just call a function "Get out of Bed" and it would know how to do it.

In assembly, the same things would have to be coded like this:

Getting out of bed:

Take off bedspread
Take off sheet
Sit up
Move legs 90 degrees
move forward
stand up
turn towards door
move forward

you get the idea.

[Fantastik]

"easy" and "hard" are all relative.

The closer the language is to machine langugae (of which assembly is just a set of alises for direct machine language, so its the closest you can get) the more simple each instruction becomes. This does not mean that its "easier".

Assembly is a set, depending on the archetecture of the chip, of perhaps 200 instructions. Of those 200, you might use 50 of them alot, with the other 150 hardly ever used. Compared to C, you have maybe 70 instructions, of which you use perhaps 25 instructions all the time. There are alot more instructions in assembly, but each instruction is "smaller" and does jsut a little step of what a larger C instruction would do.

So when you code in assembly, you have alot of grunt work to do, for each C instruction. Thats whats makes assembly hard. Miss one of the small gruntwork steps, and the program dies.

The other big channelbge is effeciency in assembly. Since its teh closest you can get to machine language, it can be the most effecient language IF you know the FULL set of instructions for your chip, AND you know WHEN to use them, and in what ORDER. Order is a big thing higher level programers dont appreciate. Because of the pipelines of modern cpus, just rearanging the order of assembly instructions can give you a 10x speed increase in some cases.

All this wierd complexity and grunt work is what makes assembly "harder" than C. In C, the compiler takes care of it all for you. You trust the compiler to optimize you C code int eh best possbile way. Oftentimes, it does not. For most things, this doesnt matter. In a tight loop that runs hundreds of millions of times per second, this might matter. THATS when you disassemble your C program, look what its doing there, and perhaps re-write the loops yourself in assembly to speed it up. THATS where assembly is the most useful imho.

Btw, when I use C here, I dont meant C++, just C. C++ is one stop higher on the pople from C. Its even more abstract and compilers, ect have a harder time optimizing it than straight C. The higher the language, the harder to optimize it (generally).

[sea4th]

I think the use of Opcodes in ShowEQ created the idea that an assembler was being used and one needs assembly language to make ShowEQ work.

If this is the intent of the original thread then the Opcodes used in ShowEQ are not assembly language at all. They are shortcuts or identifiers that Everquest uses to initiate an action. One of the header files in ShowEQ is called opcodes which associates the binary number of the opcode with the symbolic name. And SOE changes the binary assignments from time to time requiring a rediscovery by the developers of showEQ to rematch them to the actions.

Regards --