We're implementing a vector unit for RISC-V and would like to stick with op-codes that someone has already made a target of their compiler. And, we'd like to reuse an existing implementation, as much as possible. We know about Raven but can't seem to locate the Chisel source code for it. And we know about Hwacha, but it seems to deviate quite a bit from the current RISC-V vector extension proposal. Anyone know where the Raven source code is, or whether there's anything else out there?
Thanks,
Sean
Related
I'm trying to generate a walking gait for a 6-legged robot with drake. I haven't been able to find any (fully documented) examples of what I'm currently trying to do, but the classes I see in the c++ documentation lead me to believe it might be possible.
I found this paper a great "guide" for what to do.
My understanding of the steps to solving this problem are as follows:
Derive the manipulator equation for the 6-legged hexapod/make drake compute this automatically
Figure out how to add the constraints from the aforementioned paper to a mathematical program with the contact forces and control inputs as decision variables
Experiment with different cost-functions (like the one used for the fastrunner gait, also in the paper)
The classes used in this folder would be quite usefull, but I don't know how to use these in pydrake (I didn't see any bindings for them in the pydrake documentation other than staticequilibrium problem)
My questions are as follows:
Is it even possible to do this with drake?
How can you use the Manipulatorequationconstraintclass as well as the other classes in the aforementioned folder in pydrake?
Is my understanding of the problem complete, and if not what am I missing?
I realize this is probably a very scattered question, I'm very inexperienced and doubly lost ;), but any pointers in the right direction would be greatly appreciated!
Yes, it's definitely possible to use Drake for this. This LittleDog notebook example is pretty similar to what you're trying to do. Unlike the Posa reference, this example fixes the gait (foot contact sequence), but for each gait it uses optimization to solve for all of the motions.
The title pretty much sums it up. I have a homemade CPU with my assembly language called scratchy that I'd like to write code for more effectively, but I imagine there MUST be a smart place to start.
As well as LLVM, as suggested in a comment by #SK-logic, you might want to look at the portable C compiler (pcc), which is possibly simpler to write a backend for.
Good luck!
What should I know about code obfuscation in Delphi?
Should I or shouldn't I do it?
How it is done and is there any good tools (commercial/free) to automate it?
Why would you need to?
As a whole Delphi does not decompile back, unlike .net, so, while decompilation is always a bit of a risk, Ive never found a decompiler that actually did it to a useful way, lots of areas got left as assembler and so on.
If people want to rework your work, they can, no matter what, obfuscation or not, heck, some coders write almost naturally obfuscated code (having worked with a few)
My vote therefore, is shouldnt bother. Unless someone can show me a decompiler for delphi that really works, and produces full sets of compilable, and all delphi where it was originally, I wouldnt worry one drop.
Pythia is a program that can obfuscate binaries (not the source) created with Delphi or C++ Builder. Source code for Pythia is here.
Before:
After:
There's no point obfuscating since the compiler already does that for you.
There is no way to re-create the source code from the binary.
And components can be distributed in a useful way without having to distribute the source code.
So there usually is no (technical) reason for distributing the source code.
You could do other things to reduce an attacker's ability to disable your software activation system, for example, but in a native-compiled system like Delphi, you can't recreate source code from the binaries. Another answer (the accepted one at the moment) says exactly this, and someone else pointed out a helpful tool to obfuscate the RTTI information that people might use to gain some insight into the internals of your software.
You could investigate the following hardening techniques to block modification of your system, if that's what you really want:
Self-modifying code, with gating logic that divides critical functions of your code such as software activation, into various levels of inter-operable checksums, and code damage and repair.
Debug detection. You can detect debuggers being used on your software and attempt to block the software from working in this case.
Encrypt the PE binary data on disk, and decrypt it either at load time, or just in time before it runs, so that critical assembler code can not be so easily reverse engineered back to assembly language.
As others have stated, hackers working on your software do not need to restore the original sources to modify it. They will attempt, if they try it at all, to modify your binaries directly, and will use a detailed and expansive knowledge of assembler language to circumvent things you may wish them not to.
You can use free JCF (Jedi Code Formatter) to obfuscate your source code. However, pascal syntax does not allow strong obfuscation and JCF even doesn't do it's best (well, it's a code formatting tool, not obfuscator!)
I've skimmed Programming in Lua, I've looked at the Lua Reference.
However, they both tells me this function does this, but not how.
When reading SICP, I got this feeling of: "ah, here's the computational model underlying scheme"; I'm trying to get the same sense concerning Lua -- i.e. a concise description of it's vm, a "how" rather than a "what".
Does anyone know of a good document (besides the C source) describing this?
You might want to read the No-Frills Intro to Lua 5(.1) VM Instructions (pick a link, click on the Docs tab, choose English -> Go).
I don't remember exactly where I've seen it, but I remember reading that Lua's authors specifically discourage end-users from getting into too much detail on the VM; I think they want it to be as much of an implementation detail as possible.
Besides already mentioned A No-Frills Introduction to Lua 5.1 VM Instructions, you may be interested in this excellent post by Mike Pall on how to read Lua source.
Also see related Lua-Users Wiki page.
See http://www.lua.org/source/5.1/lopcodes.h.html . The list starts at OP_MOVE.
The computational model underlying Lua is pretty much the same as the computational model underlying Scheme, except that the central data structure is not the cons cell; it's the mutable hash table. (At least until you get into metaprogramming with metatables.) Otherwise all the familiar stuff is there: nested first-class functions with mutable local variables (let-bound variables in Scheme), and so on.
It's not clear to me that you'd get much from a study of the VM. I did some hacking on the VM a while back and it's a lot like any other register-oriented VM, although maybe a bit cleaner. Only a handful of instructions are Lua-specific.
If you're curious about the metatables, the semantics is described clearly, if somewhat verbosely, in Section 2.8 of the reference manual for Lua 5.1. If you look at the VM code in src/lvm.c you'll see almost exactly that logic implemented in C (e.g., the internal Arith function). The VM instructions are specialized for the common cases, but it's all terribly straightforward; nothing clever is involved.
For years I've been wanting a more formal specification of Lua's computational model, but my tastes run more toward formal semantics...
I've found The Implementation of Lua 5.1 very useful for understanding what Lua is actually doing.
It explains the hashing techniques, garbage collection and some other bits and pieces.
Another great paper is The Implmentation of Lua 5.0, which describes design and motivations of various key systems in the VM. I found that reading it was a great way to parse and understand what I was seeing in the C code.
I am surprised you refer to the C source for the VM as this is protected by lua.org and the tecgraf/puc rio in Brazil specially as the language is used for real business and commercial applications in a number of countries. The paper about The Implementation of lua contains details about the VM in the most detail it is permitted to include but the structure of the VM is proprietary. It is worth noting that versions 5.0 and 5' were commissioned by IBM in Europe for use on customer mainframes and their register-based version have a VM which accepts the IBM defined format of intermediate instructions.
Does anyone know if Lua has been certified to run on an airframe or road vehicle? Certification processes such as DO178B (RTCA) or standardization such as ISO 26262 (Road vehicles).
Certification is like case law and I would feel more confident evaluating the language knowing that another company has successfully made it through a process.
I'm betting no because of GC and dynamic features, but I thought I'd throw the question to the crowd anyway. Cheers.
DO178 Level D would be doubtful and higher would be impossible. The Lua VM uses lots of dynamic memory allocation. For Level A you need to show source to object code tracability. I don't see you doing that in Lua.
Also there is no ready made tools for everything you need. Doing everything yourself is not really an option once you realise all the work required on level C or higher. Using recognized tools with ready certification packs makes it a lot easier. Is there any statement and branch coverage tools for Lua? Is this tool qualified?
As you said certification is like case law and authorities know C and is not going to question anything if you use C. As soon as you use anything else you are opening yourself up for all kinds of questions about interpretation and implementation.
I would love to use Ruby on a aircraft but I know it is not going to happen.
Not exactly what you asked for, but this can give you an idea of what to expect:
Esterel Technologies justified the use of OCaml for the latest version of Scade, which is a code generator used in certified environments.
Note that it was not about having a language with dynamic allocation run inside the vehicle! OCaml had to be qualified as the code generator for the code generator!
If I had to summarize the article in one sentence, it would be "it was a lot of work".