There are several JIT libraries, but is there any which emits Motorola 68000 style instructions, such as for instance 68000, 68040, 68060 or any of the Coldfire CPUs?
Bonus points if it could emit for other platforms too, but 68k is most important.
Something easily integrated with C is preferred, but other languages are interesting too.
Ideally something like libjit, but with a 68k backend.
Although this doesn't really answer your question, you could consider generating the 68k machine code yourself. It shouldn't be too terribly difficult if you are already familiar with 68k assembly.
The Motorola M68000 Family Programmer's Reference Manual documents the syntax, availability, and bit configuration of every 680x0 instruction. However, a less tedious way to figure out the machine code for instructions is to use a 68k assembler that can generate a listing of the hex codes for each instruction produced. If you're on Windows, Easy68K should be able to generate such a listing, but I haven't tried it myself.
If you're not on Windows, you could try this assembler (only supports 68000, I think). You'll have to blow the dust off of it, but it works (at least in Linux). The command-line assembler (assembler/asm) has a -l flag that tells the assembler to generate a listing. Example:
$ asmlab/assembler/asm -ln test.asm
68000 Assembler by PGM
No errors detected
No warnings generated
test.asm
Leading space is required before each instruction, and the assembler doesn't handle whitespace between tokens well.
move.l #$12345678,-(a6)
jmp ($12345678)
rts
test.LIS
00000000 2D3C 12345678 1 move.l #$12345678,-(a6)
00000006 4EF9 12345678 2 jmp ($12345678)
0000000C 4E75 3 rts
No errors detected
No warnings generated
Related
I am writing real mode function, which should be normal function with stackframes and so, but it should use %sp instead of %esp. Is there some way to do it?
GCC 5.2.0 (and possible earlier versions) support 16-bit code generation with the -m16 flag. However, the code will almost certainly rely on 32-bit processor features (such as 32-bit wide registers), so you should check the generated assembly carefully.
From the man pages:
The -m16 option is the same as -m32, except for that it outputs the
".code16gcc" assembly directive at the beginning of the assembly output
so that the binary can run in 16-bit mode.
Firstly, gcc could build 16bit code, because the linux kernel is go through realmode to protectmode, so it could even build 16bit c code.
Then, -m16 option is supported by GCC >= 4.9 and clang >= 3.5
gcc will ignore asm(".code16"),you can see it by -S output the assembly code surround by #APP #NO_APP
the linux kernel do the trick to compile 16bit c with a code16gcc.h(only have .code16gcc) pass to gcc compile params directly.
see Build 16-bit code with -m16 where possible, also see the linux kernel build Makefile
if you direct put the asm(".code16gcc"), see Writing 16-bit Code, it's not real 16bit code, call, ret, enter, leave, push, pop, pusha, popa, pushf, and popf instructions default to 32-bit size
GCC does not produce 8086 code. The GNU AS directive .code16gcc can be used to assemble the output of GCC to run in a 16-bit mode, put asm(".code16gcc") at the start of your C source, your program will be limited to 64Kibytes.
On modern GCC versions you can pass the -m16 argument to gcc which will produce code to run in a 16-bit mode. It still requires a 386 or later.
As far as I know, GCC does not support generation of code for 16-bit x86. For legacy bootloaders and similar purposes, you should write a small stub in assembly language to put the cpu in 32-bit mode and pass off execution to 32-bit code. For other purposes you really shouldn't be writing 16-bit code.
I am trying to learn function call grammar in arm architecture and i compiled same code for user mode app and loadable kernel module. in attached picture you can see disassembly result for same function in two different mode. i am curious about reason of this difference.
You have compiled the code with wildly different options. The first is ARM (32bit only) and the 2nd is Thumb2 (mixed 16/32bit); see hex opcodes at the side. Thumb2 used the first 8 registers in a compact way (16bit encodings) so the call interface is different. Ie, fp is r7 versus r12. This is why you are seeing different call sequences for the same code.
Also, the first has profiling enabled (why __gnu_mcount_nc is inserted).
It really has nothing to do with 'kernel' versus 'user' code. It is possible to compile user code with similar option as the kernel uses. There are many gcc command line options which affect the 'call interface' (search AAPCS for more information and the gcc ARM options help).
Related: ARM Link and frame pointer
When I debug a C project, I can see all the assembly codes it compiles into. I want to know what assembly language that it. Is it NASM or MASM or something else? And if I use inline assembly, will I be able to use some other assembly language?
The code it compiles to is not assembly, but straight machine code, at least after link-time optimizations. What you see while debugging is on-the-fly disassembly of the machine code that is currently executing. As such, it has no additional structure, such as labels, macros, etc. such that you would expect to find in high-level assemblers, because this extra information is lost (or, more accurately, never present), when producing machine code.
If you meant the syntax, Visual Studio shows the assembly directives in Intel syntax, which is different from AT&T syntax, which is a default with GCC and GNU assembler.
In fact, it may also be gibberish. If you jmp out of alignment (x86 instructions are variable-length), or to a region that does not contain executable code, but rather data, the disassembler will try to make sense of the data, producing random assembly directives that don't mean anything.
This is actually quite common; see for example this image:
add byte ptr [rax], al is the attempted disassembly of bytes 00 00, which obviously does not represent actual executable code.
MSVC can compile binaries for x86, x86_64, ARM and Itanium. So it depends on your target and project settings
For X86 or X86-X64, Visual Studio includes ML.EXE (MASM 6.00 and later versions were renamed to ML.EXE) for 32 bit code and ML64.EXE for 64 bit code. On a VS project, you can right click on a file name, then properties, ... output files, ... assembly listing ... . The command line option for assembly listing is /Fa. Although called assembly only listing, it produces assembly code.
In Windows, can __asm nop be swapped for asm volatile("nop"); (used in GCC compiler) and yield the same result?
I have read that volatile() (in GCC) guarantees the call will not be optimized away. However, it doesn't port directly to Windows, and I was curious if it can simply be removed or if it needs to be replaced with a similar construct.
The __asm keyword implementation is quite simplistic in MSVC. It always emits the machine code unaltered and the optimizer doesn't touch it. Nor does it make any assumptions about machine state after the __asm, that has a knack for defeating other optimizations.
So, no, nothing similar to volatile() is required, it can't disappear. Plain __asm { nop } will always survive unscathed and is equivalent to the GCC assembly.
Do keep in mind that inline assembly is not a good long-term strategy, support for it was removed completely in the x64 compiler and is pretty unlikely to ever come back. You'll have to fall back to intrinsics or link code written in assembly and compiled with, say, ml64.exe. That does defeat NOP injection, but code alignment is already well taken care of by the optimizer and doesn't need help. Also the reason you probably should not do this at all.
For the Microsoft compiler, use the __nop() intrinsic function to emit a nop instruction without handicapping the compiler's optimizer. This would also be cross-platform across all Windows targets (32 bit ARM V7, 64 bit ARM V8, IA32, X64).
i am designing a compiler in c . but for certain problems like big integers i have to code in assembly code . so how can i integrate assembly code in c?
i am wrting my code in dev cpp.. which i suppose uses gcc ... in windows..!!..
pls give me instructions for linux too
using asm
Good article : GCC-Inline-Assembly-HOWTO
Use the 'asm' instruction, e.g.
asm("movl %ecx %eax"); /* moves the contents of ecx to eax */
Don't you compile the runtime with your own compiler?
Note that another option is to use an external assembler (like AS). Less optimal, but the principle is portable. (though assembler syntaxes vary wildly)
Our own little compiler (which is GCC linking compatible) used AS for most of its assembler, and only acquired an own internal assembler after 8 year or so.
P.s. if you implement an internal assembler, have a look at NASM, their tables of assembler instructions and their addressing are really clean and can be often get converted (and used for regular updates for new instructions)