The strange issue happens on the ARM32 platform. I need to run a time-series database to store and process my sensor data on an edge device. I don't have many options as some popular databases can't run on a device with very small storage capabilities. After few cycles of evaluation, I found an open-sourced time-series database TDengie seems perfectly matched my requirements since it's powerful and small enough. But when I compile and run it on my ARM32 board, it hangs the whole system. I have tried it on my X86 Linux machine and even Raspberry Pi 4 and it doesn't have such an issue. I doubt it's a special bug that exists on ARM32 only. I spent some time debugging. and I found it hands on a piece of code in the src\query\src\qExecutor.c.
*(double *)pCtx->pOutput = *(double *)pCtx->pOutput + pInput->dsum;
It works great on the X86 and Raspberry Pi but always failed on ARM32. I don't have sufficient knowledge about ARM platform-specific instruction C program generated.
Appreciated if someone can help out on this?
I guess it must be a memory align issue. You can check if the memory address of pCtx->pOutput. If it is not a 4-byte value, it would lead a bus error as the ARM assembly instruction vstr requires.
A quick solution could be using a temporary variable to make the value to be stored the assign the temporary variable's value to the target address.
You may want to try TickTock (https://github.com/ytyou/ticktock), a lightweight TSDB. We have tested it in RPi zero wireless (32bit).
Disclaimer: I am co-author of TickTock. It is still being stress-test and not in production yet.
I am porting Quake 2's inline assembly code for MSVC to MASM then finally to GAS (for use with MinGW). The specific code in question is for the Skin drawing (R_PolysetCalcGradients for those who want to look it up). The code almost "works" what happens is the skin seems to stretched over the model incorrectly.
A few interesting things I noticed is when I run objdump -dwrC r_polysa.obj > r_polysa.masm and the same for the GAS version the code is mostly similar except for the fact fsubp and fsubrp have been swapped in MASM. Please note not the operands (I already know about this issue in GAS).
In the picture the left side is the GAS version, the right side is the MASM version. The original MASM code (and therefore what I have in GAS) is what should be on the left side. I am unsure why MASM is apparently swapping this or if objdump is reporting it incorrectly. However, if I swap the two this does not fix the issue. It just gets inverted in another wrong way.
I mention this FSUBP/FSUBRP swap because this was a problem in porting the Particle blending inline ASM code. This had one call to use an FSUBRP in the MASM version, objdump reported it now being FSUBP and I had to change it to FSUBP in the GAS version for it to work! I don't understand why this is happening?
In any case, I am new to assembly, but understand some basics and have been doing some reading. Obviously the math here is not quite right, but it seems as though it should be. I don't know how or what to do next. How do I fix and debug this problem?
The code repository to what I am working on is at: https://bitbucket.org/neozeed/q2dos/commits/branch/win32_asm (specifically the Win32_ASM branch). The files I am working with are gas\r_polysa.s and ref_soft\r_polysa.asm.
Opcodes were reversed so there is a quirk with GAS and fsubrp following an fsubp. There was one other additional gotcha, unrelated to that issue. For those interested see: https://bitbucket.org/neozeed/q2dos/commits/f5bf93e3a78e112ae1f766606471a6c5e67283d4
Link to MIRACL crypto library by CertiVox
Following the instructions in fastgf2m.txt, I've been able to get everything to compile. However, after execution, the benchmark (bmark.exe) program halts when evaluating curves over GF(2^m) with error, "This is not a point on the curve!"
I am able to get everything to work without the optimization but I'm unsure where the problem exists. I haven't modified any curve parameters and followed instructions in the distribution. I'm compiling on 64-bit Windows 8.1, on an Intel i7-3520M.
If anyone has any advice on how to correct this, it would be greatly appreciated.
Thanks!!
The method outlined in fastgf2m.txt is for generating unrolled code associated with a fixed m value determined at compile time. The bmark program changes m at runtime, and so the unrolled code will often not be correct in this case. The documentation could be clearer on this point.
Also make sure your processor does support the PCLMULQDQ instruction - many older processors will not.
It might be better to test the method on the ecsgen2/ecssign2/ecsver2 programs to implement ECDSA over GF(2^283) for example.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Running/Interpreting C on top of the JVM?
By hybrid language I mean one that is compiled by a hybrid compiler (like Java). I understand it would be impracticable, because C is designed to be easily mapped to machine instructions, but I can't tell if there are any reasons why someone couldn't write a hybrid compiler for it.
Creating a custom virtual machine designed for running C would of course work, and work very well, with 1-1 mapping for many byte code instructions to real CPU instructions, and easy and fast JITing as a result too. Actually, LLVM for example is actually very much like this.
Doing C compiler targetting JVM would probably require making C heap to be a Java byte[] array, and pointers would be indexes to this array. Also C variables in stack might need to be done with simulated byte[] stack too, since it must be possible to get a pointer to them (compatible with heap pointer).
This is needed, because with direct Java refrences, it would be impossible to do pointer arithmetic and integer-pointer casts in C. One option to optimize this could be to make C char be 32 bits, which is allowed by C standard, but it would make that C implementation very awkward to use for processing for example text files, or anything really with byte data... Regardless, C compiled to Java bytecode would be very slow, as Java byte code can not do many C things "natively" with single byte code instructions.
C compilers exist for many architectures. Bytecode that Java uses probably can be simply viewed as just one more instruction set so why should not be possible? Probably pointers would not be a "real pointers" but some internal VM references.
Used to be a commercial compiler provided by axiomsol but all links to it appear dead (404) now.
Compiling C into Java code and then compiling Java is possible but many thinks seem really resolved in suboptimal way. With byte[], you even cannot read an integer in one go. C would probably benefit from its own virtual machine that would be simpler (as no garbage collector required). Or, at least, C must be compiled into bytecode directly. Who knows C well could look into the JamVM project that may provide an interesting start. It is a simple virtual machine to run Java bytecode.
I googled and I see a surprising amount of flippant responses basically laughing at the asker for asking such a question.
Microchip provides some source code for free (I don't want to post it here in case that's a no-no. Basically, google AN937, click the first link and there's a link for "source code" and its a zipped file). Its in ASM and when I look at it I start to go cross-eyed. I'd like to convert it to something resembling a c type language so that I can follow along. Because lines such as:
GLOBAL _24_bit_sub
movf BARGB2,w
subwf AARGB2,f
are probably very simple but they mean nothing to me.
There may be some automated ASM to C translator out there but all I can find are people saying its impossible. Frankly, its impossible for it to be impossible. Both languages have structure and that structure surely can be translated.
You can absolutely make a c program from assembler. The problem is it may not look like what you are thinking, or maybe it will. My PIC is rusty but using another assembler, say you had
add r1,r2
In C lets say that becomes
r1 = r1 + r2;
Possibly more readable. You lose any sense of variable names perhaps as values are jumping from memory to registers and back and the registers are being reused. If you are talking about the older pics that had what two registers an accumulator and another, well it actually might be easier because variables were in memory for the most part, you look at the address, something like
q = mem[0x12];
e = q;
q = mem[0x13];
e = e + q;
mem[0x12] = e;
Long and drawn out but it is clear that mem[0x12] = mem[0x12] + mem[0x13];
These memory locations are likely variables that will not jump around like compiled C code for a processor with a bunch of registers. The pic might make it easier to figure out the variables and then do a search and replace to name them across the file.
What you are looking for is called a static binary translation, not necessarily a translation from one binary to another (one processor to another) but in this case a translation from pic binary to C. Ideally you would want to take the assembler given in the app note and assemble it to a binary using the microchip tools, then do the translation. You can do dynamic binary translation as well but you are even less likely to find one of those and it doesnt normally result in C but one binary to another. Ever wonder how those $15 joysticks at wal-mart with pac-man and galaga work? The rom from the arcade was converted using static binary translation, optimized and cleaned up and the C or whatever intermediate language compiled for the new target processor in the handheld box. I imagine not all of them were done this way but am pretty sure some were.
The million dollar question, can you find a static binary translator for a pic? Who knows, you probably have to write one yourself. And guess what that means, you write a disassembler, and instead of disassembling to an instruction in the native assembler syntax like add r0,r1 you have your disassembler print out r0=r0+r1; By the time you finish this disassembler though you will know the pic assembly language so well that you wont need the asm to C translator. You have a chicken and egg problem.
Getting the exact same source code back from a compiled program is basically impossible. But decompilers have been an area of research in computer science (e.g. the dcc decompiler, which was a PhD project).
There are various algorithms that can be used to do pattern matching on assembly code and generate equivalent C code, but it is very hard to do this in a general way that works well for all inputs.
You might want to check out Boomerang for a semi-recent open source effort at a generalized decompiler.
I once worked a project where a significant part of the intellectual property was some serious algorithms coded up in x86 assembly code. To port the code to an embedded system, the developer of that code (not me) used a tool from an outfit called MicroAPL (if I recall correctly):
http://www.microapl.co.uk/asm2c/index.html
I was very, very surprised at how well the tool did.
On the other hand, I think it's one of those "if you have to ask, you can't afford it" type of things (their price ranges for a one-off conversion of a project work out to around 4 lines of assembly processed for a dollar).
But, often the assembly routines you get from a vendor are packaged as functions that can be called from C - so as long as the routines do what you want (on the processor you want to use), you might just need to assemble them and more or less forget about them - they're just library functions you call from C.
You can't deterministically convert assembly code to C. Interrupts, self modifying code, and other low level things have no representation other than inline assembly in C. There is only some extent to which an assembly to C process can work. Not to mention the resultant C code will probably be harder to understand than actually reading the assembly code... unless you are using this as a basis to begin reimplementation of the assembly code in C, then it is somewhat useful. Check out the Hex-Rays plugin for IDA.
Yes, it's very possible to reverse-engineer assembler code to good quality C.
I work for a MicroAPL, a company which produces a tool called Relogix to convert assembler code to C. It was mentioned in one of the other posts.
Please take a look at the examples on our web site:
http://www.microapl.co.uk/asm2c/index.html
There must be some automated ASM to C translator out there but all I can find are people saying its impossible. Frankly, its impossible for it to be impossible.
No, it's not. Compilation loses information: there is less information in the final object code than in the C source code. A decompiler cannot magically create that information from nothing, and so true decompilation is impossible.
It isn't impossible, just very hard. A skilled assembly and C programmer could probably do it, or you could look at using a Decompiler. Some of these do quite a good job of converting the asm to C, although you will probably have to rename some variables and methods.
Check out this site for a list of decompilers available for the x86 architecture.
Check out this: decompiler
A decompiler is the name given to a
computer program that performs the
reverse operation to that of a
compiler. That is, it translates a
file containing information at a
relatively low level of abstraction
(usually designed to be computer
readable rather than human readable)
into a form having a higher level of
abstraction (usually designed to be
human readable).
Not easily possible.
One of the great advantages of C over ASM apart from readability was that it prevented "clever" programing tricks.
There are numerous things you can do in assembler that have no direct C equivalent,
or involve tortuous syntax in C.
The other problem is datatypes most assemblers essentialy have only two interchangeable datatypes: bytes and words. There may be some language constructs to define ints and floats
etc. but there is no attempt to check that the memory is used as defined. So its very difficult to map ASM storage to C data types.
In addition all assembler storage is essentially a "struct"; storage is layed out in the order it is defined (unlike C where storage is ordered at the whim of the runtime). Many ASM programs depend on the exact storage layout - to acheive the same effect in C you would need to define all storage as part of a single struct.
Also there are a lot of absused instructions ( on olde worldy IBM manframes the LA, load address, instruction was regulary used to perform simple arithimatic as it was faster and didnt need an overflow register )
While it may be technically possible to translate to C the resulting C code would be less readable than the ASM code that was transalated.
I can say with 99% guarantee, there is no ready converter for this assembly language, so you need to write one. You can simply implement it replacing ASM command with C function:
movf BARGB2,w -> c_movf(BARGB2,w);
subwf AARGB2,f -> c_subwf(AARGB2,f);
This part is easy :)
Then you need to implement each function. You can declare registers as globals to make things easy. Also you can use not functions, but #defines, calling functions if needed. This will help with arguments/results processing.
#define c_subwf(x,y) // I don't know this ASM, but this is some Substraction must be here
Special case is ASM directives/labels, I think it can be converted with #defines only.
The fun starts when you'll reach some CPU-specific features. This can be simple function calls with stack operations, some specific IO/Memory operations. More fun are operations with Program Counter register, used for calculations, or using/counting ticks/latencies.
But there is another way, if this hardcore happens. It's hardcore too :)
There is a technique named dynamic recompilation exists. It's used in many emulators.
You don't need recompile your ASM, but the idea is almost the same. You can use all your #defines from first step, but add support of needed functionality to them (incrementing PC/Ticks). Also you need to add some virtual environment for your code, such as Memory/IO managers, etc.
Good luck :)
I think it is easier to pick up a book on PIC assembly and learn to read it. Assembler is generally quite simple to learn, as it is so low level.
Check out asm2c
Swift tool to transform DOS/PMODEW 386 TASM Assembly code to C code
It is difficult to convert a function from asm to C but doable by hand. Converting an entire program with a decompiler will give you code that can be impossible to understand since to much of the structure was lost during compilation. Without meaningful variable and function names the resultant C code is still very difficult to understand.
The output of a C compiler (especially unoptimised output) of an basic program could be translatable to C because of repeated patterns and structures.