Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I'd like to learn how to program in Assembler. I've done a bit of assembly before (during my A-Level Computing course) but that was very definitely a simplified 'pseudo-assembler'. I've borrowed my Dad's old Z80 Assembler reference manual, and that seems quite interesting so if possible I'd like to have a go with Z80 assembler.
However, I don't have a Z80 processor to hand, and would like to do it on my PC (I have windows or linux so either is good). I've found various assemblers around on the internet, but I'm not particularly interested in assembling down to a hex file, I want to just be able to assemble it to something that some kind of simulator on the PC can run. Preferably this simulator would show me the contents of all the registers, memory locations etc, and let me step through instructions. I've found a few bits of software that suggest they might do this - but they either refuse to compile, or don't seem to work properly. Has anyone got any suggestions? If there are good simulator/IDE things available for another type of assembler then I could try that instead (assuming there is a good online reference manual available).
I've found a few bits of software that suggest they might do this - but they either
refuse to compile, or don't seem to work properly. Has anyone got any suggestions?
Write one. You're best off picking a nice, simple instruction set (Z80 should be perfect). I remember doing this as a first-year undergraduate exercise - I think we wrote the simulator in C++ and simulated 6800 assembly, but really any language/instruction set will do.
The idea of "learning assembly language" these days is to get the idea of how computers work at the lowest level, only a select few (compiler writers, etc.) have any real reason to actually be writing assembly code these days. Modern processors are stuffed full of features designed to be used by compilers to help optimise code for speed/concurrent execution/power consumption/etc., and trying to write assembly by hand for a modern processor would be a nightmare.
Don't fret about getting your application production-ready unless you want to - in all likelihood the bits of software you've found so far were written by people exactly like you who wanted to figure out how assembly works and wrote their own simulator, then realised how much work would be involved in getting it "production ready" so the general public could use it.
You might want to check out the open source 8085 simulator "GnuSim8085", it's specifically meant to be used for educational purposes, and it was in fact written by student while preparing for his exams. It runs on both, Linux and Windows.
WinApe is a good emulator of an Amstrad CPC. The Amstrad CPC was a Home Computer produced in the 80's. It used a Z80 as its CPU. Using the emulator you can display a lot of the internals while programming. It includes a debugger and a disassembler for Z80 code.
If Your are on windows 8085 Simulator is the best choice.
It user interface is excellent than any other simulator. Also this simulator provide live view of memory map very time(also while in the execution).
But this one does not support Windows 98 or lower for that you need to check other simulators like GNUSim8085.
MipSim is FREE
Main Features of MIPSim 2
Built-in code editor with features like syntax highlighting and folding
Display register and memory values in different representations (signed integer, unsigned integer, hexadecimal and ASCII)
Set the block size (full-word, half-word, byte) of the memory cells for easier examination of the memory values
Change values of registers and memory cells with a single click even during simulation and debugging
Realtime user-interface updating allows you to see how values of registers and memory cells change during execution
Built-in debugger with step-by-step instruction execution, instruction skipping and breakpoint features
Tools for inserting ASCII, UNICODE strings and integer values to memory for testing of your code
Tools for checking duplicate or missing labels and instruction parameters
Save computer state (values of all registers and memory cells) so that next time you run the simulator you can continue from where you left!
Set the simulation speed - low speeds are great to trace your code and to see how it behaves
Encode instructions - produce machine code in either binary or hexadecimal representation
Catch assembly time and runtime errors
Easier debugging with descriptive error messages
Multi-threaded design - MIPSim doesn't get stuck (hopefully ;) even if the assembly code executed is erroneous or contains infinite loops
MIPSim API - make your own programs that can read from and write to the registers and memory of MIPSim, great flexibility for powerful testing!
Aim higher! Try and get a simulator for a more powerful assembly language. Remember, Z80 and 808x were low-end processors with low-end and awkward instruction sets.
Something like VAX from DEC was regarded as the Rolls-Royce of instruction sets. And then there are crazy Risc instruction sets that do some really strange things. Maybe you can find definitions of those so that you can have a crack at implementing them.
You may be interested in this for a Z80 simulator, and I've had good experiences with WinAsm.
You might also consider learning x86 assembly language, which you could do using in-line assembler in Visual Studio - although it's a larger instruction set than Z80, you would have the advantage of being able to use much better tools than would be available for the Z80.
I've also just remembered that the Keil 8051 and Arm tools have a simulator in the IDE - there are size-restricted versions of these available for free download from www.keil.com
If you happen to already know .NET, then this may be of use:
http://www.viksoe.dk/code/asmil.htm
It's a little bit limited, and may only work with .NET 1.1, but you could atleast use a "modern" IDE for it, and there are plenty of docs around for it.
<%# page language="Asm80386" %>
<%
Str: DB "Testing...", 0
mov eax, -2
cmp eax, 2
jle Label1
xor eax, eax
Label1:
lea esi, Str
push esi
call "Response.Write(string)"
pop esi
%>
<br>EAX: <%= eax %>
Another option, if you want to go "hard core" is get something like FreeDOS and VMWare, and use that. I'm sure a garage sale (car boot sale? yard sale?) or second hand book shop would have a copy of Peter Norton's old DOS interrupts bible. :)
Personally, I learned x86 asm by using Turbo Pascal (which I think is now free from Borland?), which had the ability to embed assembly instructions inside a function. Made it easier to setup the app, and I could focus on the stuff I wanted to do. I later used MacVAX at Auckland Uni, which was ok, but the VAX is very much dead - you may as well learn x86 :)
SimpSim is definitely worth a look. It's Windows only, but the feature set is pretty decent:
Main memory and register display
Built-in editor with syntax highlighting
Run, step, and break functions
This wouldn't make any meaning to you now but just for people stopping by. This is the best assembly code simulator I have come across with. Truly worth it!
http://www.emu8086.com/
Take a look at Thomas Scherrer Z80 Emulators for a listing of potential emulators you could use.
I write z80 asm for the ZX Spectrum (still, I know :) ) and use SJasmPlus to link to a spectrum emulator file. Lots of of the better Spectrum emulators like Fuse and ZXSpin have built in editors as well for on the fly debugging and patching.
When I was in college we used PIC microprocessors. They are made by a company called Microchip. They also have a great IDE with a chip emulator/simulator that can allow you to do things without actually having the chips.
Why use an emulator?
Download MASM or NASM and write good old 80386 architecture. Plenty of online samples and learning tools.
Plenty of real-world reason to use assembler!
there is a simulator which is Visual6502 for teaching fundemental of microprocessor architecture. It has a editor, assembler, I/O operation and animation of how to work a microprocessor. I is available at the following link.
http://www.pcsistem.net/visual/index.htm
Related
How are we actually supposed to include our OpenCL code in our C projects?
We can't possibly be supposed to ship our .cl files along with our executable for the executable to find them and load them at runtime, because that's stupid, right?
We can't be supposed to use some stringify macro because a) that's apparently not portable/leads to undefined behaviour and b) it all breaks down if you use commas not enclosed in brackets like when defining many variables of the same type, I've spent an hour here looking for a solution to that and there doesn't seem to be one that actually works and c) that's kind of stupid.
Are we expected to write our code into C string literals like "int x, y;\n" "float4 p;\n"? Because I'm not doing that. Are we supposed to do a C include-style hexdump of our .cl files? That seems inconvenient. What are we actually supposed to do?
It's bad enough that all these approaches basically mean that you have to ship your program with your OpenCL code essentially open sourced when your OpenCL code is probably the last thing you want open sourced, on top of it it seems every OpenCL project I've seen uses one of the approaches listed above, it just doesn't seem right at all, it's like the people who made OpenCL forgot about something.
This thread: OpenCL bytecode running on another card mentions SPIR, a "platform-portable intermediate representation for OpenCL device programs". Other than that, you are basically restrained to the options you already mentioned.
Personally, I began to use C++11 raw string literals to get rid of my nasty stringify-macros. Don't know if C++ is an option for you, however.
Concerning your rejection of the "ship our .cl files along with our executable" approach: I don't see why this is inherently stupid -- the CL "shaders" are an application resource like all other separate files beside the executable, and thus are part of the "application bundle". It's perfectly reasonable to have such kind of files, and each operating system has its way to deal with it (in win32, the program directory is the bundle https://blogs.msdn.microsoft.com/oldnewthing/20110620-00/?p=10393 , OSX has its own bundle concept, etc...).
Now, if you are worried about other people peeking into your OpenCL code, you can still apply some obfuscation methods (e.g. encrypt your .cl-files by a key which is more or less cleverly hidden in your executable).
[edit/sidenote]: We could also investigate how other companies deal with this issue in the context of, for example, OpenGL/Direct3D shaders. In my limited experience, gaming companies tend to dump their shaders in text form somewhere in their application directory, for all to see (and even to tamper with). So in the gaming world at least, there is no great deal of secrecy in that respect... Wonder what adobe or CAD software companies do in their professional software.
To start this off, I use OS X which is a UNIX based system.
I have beginner theoretical knowledge in C++ and would like to expand my knowledge by software reverse engineering. Every guide I get into seems to jump in half way and I seem to miss a giant gap of information required to start up. What my end goal is to successfully build a working dylib for any application. Where do i start with learning Ram addresses, how do they work, how are libraries loaded and what the actual hell do I start reading, what subject. Everything I've learned so far has a distinct start point, certain syntax but I just find everything uses terminology I don't understand. I find myself just branching off more and more because an article used a keyword I don't understand, I google it, the other one uses five I don't understand and I just get stuck. The application under question does not have changing memory addresses, but I would also like to learn how to compensate for it using offsets.
Where do I start?!
Before you get started with reverse engeneering you'll need more than a theoretical knowledge of the C language. Forget C++ for now, C is simpler and it's so low level that once you master it you'll understand how programs work under the hood. Get you a copy of The C Programming Language by Brian Kernighan and Dennis Ritchie and go through the whole book.
Once you feel confortable writting C programs get familiar with UNIX standards like POSIX and then move on to OS X specific stuff. The best resource for OS X programming is http://developer.apple.com. The link below explains how dynamic libraries work on OS X. Once you get a good understanding of C it will all make sense.
https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/OverviewOfDynamicLibraries.html
Since so there are so many JIT implementation out there, every JIT emits native code. Then why hasn't someone made a tool like JIT2EXE, to save the native code to a native executable?
The question is kind of vague as you have not clearly specified what language you are talking about, in my area of .NET, the .NET executables are pre-jitted at runtime in order to speed up the loading times. The code can be generated to native code by a process known as NGEN which takes the .NET IL code and converts it in the process of a binary in which can be understood by the processor. Usually NGEN code are stored in the folder within 'C:\Windows\Assembly\NativeImages_{version}' where the version represents the .NET Framework version. Have a look here on CodeGuru by Jeffrey Richter, about NGEN and where it could be used and when to use it. Have a look here on Codeproject about this article on the statistics/comparisons with native binary code and also here as well by Daniel Pistelli.
You mean something like ngen?
As a matter of fact, there are many Java (or other interpreted languages)-to-native compilers. Ever heard of gcj?
http://gcc.gnu.org/java/
There are also mixed compilers that compile some critical parts to native code and keep the others as bytecode to save space. Harissa did this more than 10 years ago.
http://www.usenix.org/publications/library/proceedings/coots97/full_papers/muller/muller_html/usenix.html
The Java code is first compiled to C code, which is then passed to the regular C compiler in order to take advantage of its optimizations. Such code can turn out to be very fast.
Of course, such ahead-of-time compilation (as opposed to just-in-time compilation) cancels some of the advantages of the bytecode form (especially portability and low memory footprint), so real-world applications are rather rare.
What you state in your question ("noone has made a tool like JIT2EXE") is not quite true:
http://en.wikipedia.org/wiki/AOT_compiler
How can I package my Java application into an executable jar that cannot be decompiled (for example , by Jadclipse)?
You can't. If the JRE can run it, an application can de-compile it.
The best you can hope for is to make it very hard to read (replace all symbols with combinations of 'l' and '1' and 'O' and '0', put in lots of useless code and so on). You'd be surprised how unreadable you can make code, even with a relatively dumb translation tool.
This is called obfuscation and, while not perfect, it's sometimes adequate.
Remember, you can't stop the determined hacker any more than the determined burglar. What you're trying to do is make things very hard for the casual attacker. When presented with the symbols O001l1ll10O, O001llll10O, OO01l1ll10O, O0Ol11ll10O and O001l1ll1OO, and code that doesn't seem to do anything useful, most people will just give up.
First you can't avoid people reverse engineering your code. The JVM bytecode has to be plain to be executed and there are several programs to reverse engineer it (same applies to .NET CLR). You can only make it more and more difficult to raise the barrier (i.e. cost) to see and understand your code.
Usual way is to obfuscate the source with some tool. Classes, methods and fields are renamed throughout the codebase, even with invalid identifiers if you choose to, making the code next to impossible to comprehend. I had good results with JODE in the past. After obfuscating use a decompiler to see what your code looks like...
Next to obfuscation you can encrypt your class files (all but a small starter class) with some method and use a custom class loader to decrypt them. Unfortunately the class loader class can't be encrypted itself, so people might figure out the decryption algorithm by reading the decompiled code of your class loader. But the window to attack your code got smaller. Again this does not prevent people from seeing your code, just makes it harder for the casual attacker.
You could also try to convert the Java application to some windows EXE which would hide the clue that it's Java at all (to some degree) or really compile into machine code, depending on your need of JVM features. (I did not try this.)
GCJ is a free tool that can compile to either bytecode or native code. Keeping in mind, that does sort of defeat the purpose of Java.
A little late I know, but the answer is no.
Even if you write in C and compile to native code, there are dissasemblers / debuggers which will allow people to step through your code. Granted - debugging optimized code without symbolic information is a pain - but it can be done, I've had to do it on occasion.
There are steps that you can take to make this harder - e.g. on windows you can call the IsDebuggerPresent API in a loop to see if somebody is debugging your process, and if yes and it is a release build - terminate the process. Of course a sufficiently determined attacker could intercept your call to IsDebuggerPresent and always return false.
There are a whole variety of techniques that have cropped up - people who want to protect something and people who are out to crack it wide open, it is a veritable arms race! Once you go down this path - you will have to constantly keep updating/upgrading your defenses, there is no stopping.
This not my practical solution but , here i think good collection or resource and tutorials for making it happen to highest level of satisfaction.
A suggestion from this website (oracle community)
(clean way), Obfuscate your code, there are many open source and free
obfuscator tools, here is a simple list of them : [Open source
obfuscators list] .
These tools make your code unreadable( though still you can decompile
it) by changing names. this is the most common way to protect your
code.
2.(Not so clean way) If you have a specific target platform (like windows) or you can have different versions for different platforms,
you can write a sophisticated part of your algorithms in a low level
language like C (which is very hard to decompile and understand) and
use it as a native library in you java application. it is not clean,
because many of us use java for it's cross-platform abilities, and
this method fades that ability.
and this one below a step by step follow :
ProtectYourJavaCode
Enjoy!
Keep your solutions added we need this more.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last month.
Improve this question
Most people suggest that learning assembly is essential, its important to know the underlying workings of the computer, and so forth. But what I'm looking for are some practical suggestions that will make the effort of learning Assembly to be worth it.
What are your suggestions? What am I missing out on by not learning Assembly and pointers/memory management in general?
I think the main practical advantage to learning low-level things like assembly language, pointers, and memory management is that when you're writing or reviewing high-level code you're better able to instinctively or subconsciously spot performance issues or other pitfalls.
An average developer, might write a simple loop and think, "This code iterates over a set of integers and writes each to the console."
An expert developer might write the same loop and think, "This code iterates over a set of integers, and has to box each element to call the ToString method and ToString has to format the string in base 10 which is somewhat non-trivial, and then both the boxed integer and the formatted string will soon be eligible for garbage collection as no references will remain, and the first time this method runs, it will need to be JIT'ed..." and so on.
9 times out of 10, it may not matter. But that 1 time out of 10, the expert developer is likely to notice a problem in code that the average developer would never think to consider.
Pointers/memory management are more general than assembly language. You need to understand them for C and C++ as well, which you might need if you have to maintain code written in C.
For assembly language, it is sometimes useful to read the assembler code that the C compiler generates, to find out whether it generates correct and efficient code.
You need to learn to read assembly so you can figure out what goes wrong when a complex statement bombs out. The CPU debug window shouldn't be a mysterious place.
This is sort of one of those questions that will always be asked: "Why should I know anything." etc. Well, perhaps you could get a job doing something besides building the next generic CRUD application or something like that. If you want to do any sort of system development, having a working knowledge of assembly is very helpful, if not vital. As far as what you're "missing out" perhaps you are missing out on actually knowing how computers work. Some people think this is desirable. Some people don't. Some people build processors. Some people dig ditches. It's all a matter of personal preference :)
I think it's great to learn new languages. It opens my mind. Some languages are more mind-opening than others. I'd say assembler is one of those. It forces you to think about stuff like the call stack and instruction pointer. And it'll make you appreciate higher level languages even more. Another fun language to learn is PostScript.
I don't think you need to learn assembly for anything practical. However, it will ensure that you understand the real roots of what you are doing as a developer. In essence, assembly programming is a discipline for learning chip logic and architecture. I haven't programmed assembly in over two decades but it still informs the kinds of choices I make when programming C#.
But what I'm looking for are some practical suggestions that will make the effort of learning Assembly to be worth it.
Learn what assembly is.
Really learn how to read (and understand) small fragments of it: how to walk/step through it in your mind.
Perhaps too, step through some of it with a debugger (including seeing memory and registers being changed).
Ideally, find some annotated assembly.
But, don't bother to learn how to write assembly: instead, learning to write C or C++ is probably 'low' enough for most practical purposes.
Well, on a practical level I did a class in 6502 assembler when I was first learning to code the early 80s. I also did some 8088 assembler. It's been of occasional use of the years since but I can't say it's ever really got my out of a hole on more than one or two occasions in 25 years. Groking C at a pretty fundamental level is of far more use. YMMV and it's certainly helpful as background, but as a direct practical benefit? Marginal really.
Perversely though one thing that has proved useful is at an even lower level. I did a class on chip design (NAND gates and the like) and as part of that was taught formal Boolean logic at some depth. That's been massively useful ever since - it's surprising the number of coders who don't really know what they are doing with ands, ors and nots :-)
Pointers and memory management are really a different question than assembly. If you want to do C/C++, then you need to learn pointers and memory management, because those are part of the language. But, even if you plan to use nothing but (say) Java all your life, you should learn something about memory management to keep from writing a memory leak despite the GC, and pointers are just the difference between atomic types and object references. You need the concepts or you'll write programs that don't work!
Practical reasons for learning assembly: debugging and optimization. Even if you don't write any assembly, one of these days you may need to optimize C/C++ code for performance. In that case, you'll need to be able to read the assembly for your inner loop, even if you never need to write another line of it.
Ultimately, I think your distinction between "knowing the underlying workings of your computer" and "practical suggestions that will make the effort of learning assembly worth it" is a false one. Ignorance does not pay. Learning how your computer works is a practical suggestion worth the effort!
I have a prophecy: someday soon, your program will run far too slowly to be practical, and crash intermittently with an out-of-memory exception. On that day, the sheer screaming anxiety of not knowing what the hell is going on or where to start looking in order to fix it will refund your karma debt, with interest...
These days many assembly languages are actually fairly high level.
And it's always been true that if you learn 'C', that's close enough to assembly to get most of the learning benefits.
edit: thinking about this a bit more, in Knuth's books he describes an idealised assembly language. You won't go far wrong learning that, and reading those books.
Another practical reason I can think of is reverse engineering application code to modify it for educational purposes ONLY, since this is widely used by crackers to bypass shareware application protections like time-limit or serial numbers.
An application like win32Dasm can convert executables into assembly code that can later be modified with a Hex editor like hiew. You can learn quite a lot about the flow of the program.
I think learning about computer architecture, in conjunction of assembly, would open your mind quite a bit.
It would help explain lots of performance issues - e.g. parser's slow because there's lots of branches, and pipeline gets flushed very easily, branch predictor cannot compensate for everything.
Also, different architectures have their quirks. Someone talked about an assembly trick to swap 2 registers in place, involving xor's. It works, and it would run great for in-order execution core (most recent example would be the Intel Atom, and the Via C7 in netbooks), but not so great in out-of-order cores.
Knowing that may help you to detect poorly compiled code by inspecting it in assembly, and possibly be able to write code in higher-level language to sidestep the imperfection of compiler optimizers. I'm not trying to diss them, but they just can't be perfectly in tuned.
The biggest practical advantage to learning Assembly is performance. You can optimize to near perfection when its required.