Detecting CPU capability without assembly - c

I've been looking at ways to determine the CPU, and its capabilities (eg SEE,SSE2,etc).
However all the ways I've found involved assembly code using the cpuid instruction. Given the differing ways of doing assembly in c/c++ between compilers and even targets (no inline assembly for 64bit targets under VC), id rather avoid that.
Is there some simple library around, or OS functions (for both windows and linux) for getting this information?
Currently I'm only interested in platforms using the x86 and x86-64 CPU's, and I defiantly need to support at least AMD and Intel.

EDIT: At first, I googled for "libcpuid" remembering a conversation with peer programmers, and the google search pointed me to this sourceforge page which looks quite outdated. Then I noticed it was the project page of "libcpu".
Actually, there really is a libcpuid that might suit your needs.
Last time I looked for such a library, I found crisscross. It's C++ though.
There is also geekinfo.
But I don't know a cross-platform library that just does cpuid.

Under linux peek in /proc/cpuinfo

This so hardware-dependent --- which is an aspect the OS usually shields you from --- that requiring it to be cross-platform is a tad hard.
It would be useful to have, but I fear you may just have to enumerate the cross-product of CPU s and features you would like to support, times the number of OSs (here two) and write tests for all. I do not think it has been done -- and someone will surely correct me if I overlooked something.
That would be a useful library to have, so good luck with the endeavor!

Related

What would be a simple to use JIT library?

I'm trying to write a language runtime (and a language itself) that is similar to .NET or to the JVM. It's got a form of bytecode that is custom.
What I want is a way to translate said bytecode to actual, runnable machine code. So, because I'm not wanting to write such a translator myself (this is more of a toy project/personal side project) I want to find a good JIT library to use.
Here's what I want the library to do:
The library should be as easy to use as possible (toy project and I don't really have much experience here)
The library should support at least x86_64 (development machine), though preferably it should cover other architectures as well
The library should preferably do some low level optimizations (register tracking and allocation, reducing memory accesses etc); those optimizations shouldn't be very expensive to do though (I will myself do other optimizations to e.g. remove virtual calls and convert them to direct ones, for example). I can accept a library with no optimization if it's easiest to use though.
The library must have an interface that is usable from C (preferred) or C++ (acceptable).
I will use Boehm GC for garbage collection, if it matters (probably doesn't, but just in case). Maybe a compacting GC would be nice, but I guess I shouldn't combine the questions...
I would suggest llvm. There are some great tutorials on how to implement your own language with it and basic stuff is not too complicated. You also get the option to do a lot of more advanced stuff later on. As a bonus not only can you use JIT but you can also statically compile and optimize your binaries. LLVM also does have a C interface and can target all common CPU architectures and even a lot of more obscure ones.

Is there any way of doing multiprecision arithmetic(with integers that are greater than 64-bit) in msp430?

I'd like to know if there is any way, if possible any simple way, to do arithmetic with integers that are larger than 64-bit in size on MSP430?
I'm asking this specifically because I'm trying to implement encryption algorithms (RSA, AES, hash functions, digital signatures, etc.) on an msp430g2553 platform.
I searched through the internet, and through a misguided despair I installed linux distributions in order to use GMP but failed miserably. I installed Kali and then later Lubuntu on a USB(2.0) stick only to suffer through the unbearable freezes, with no clue on if it would work or not. Later on tried the magic of VMBox and things got way easier after that, though inconclusive. I eventually came to a point with mps430-gcc, and mspdebug that I could debug some example codes, and see them work, but still unable to do GMP operations due to mostly library errors (undefined reference to mpz_t init... etc.).
To my understanding GMP is a multiprecision arithmetic library to work on specific processor architectures, and MSP430 is not one of them, though, at this point, I'd not be surprised if it is one of them. Best answer I got was that some TI employee is unfamiliar with it. So;
Is it possible to use GMP on MSP430, or more specifically on
msp430g2553?
I've hardly seen anything on google that has cross-reference of msp430 with gmp, and I'm at point that I'm trying to implement a miserable 64-bit key sized RSA that's barely working, if at all. So I hope this post, and its answers help someone, and hopefully to me as well, later on.
Also I forgot to mention, I've read about relic toolkit, (but didn't spend my time trying to implement it as GMP looked more like the standard in that area), and I'd like to know:
Is there a Relic guide for dummies that you can link, and again if it's possible to work with it on MSP430?
Thanks everyone.
It is unlikely that any of these libraries can be compiled for an embedded 16-bit architecture.
The MSP430 CPU has add-with-carry and similar instructions, and that is how the compiler implements 32- and 64-bit integers.
So it would be possible, in theory, to write these algorithms yourself, with lots of (inline) assembly.
But I doubt that the G2553 has enough memory for this.
(There is a reason that some larger MSP430s have an AES hardware accelerator, and that none have one for RSA.)

Why does vim rely so heavily on compile-time feature configuration?

I understand that one of the main vim's main goals are portability and customisation. Abundance of comments in the manual about things working differently on various problems does not surprise me. However, I don't understand why almost every feature can be disabled with a compile flag, what purpose does it serve? Wouldn't it be easier to be able to disable features in runtime, with some kind of configuration?
As far as I understand (I tried diving into vim code, but didn't write any patches), it makes the code base much more complicated, and that's exactly what Neovim developers are trying to remove. Why did vim developers follow this approach?
There are several forces for having many flags (some of which have already been mentioned in the comments):
portability: with quite different (and exotic, like DOS and Amiga) operating systems to support, different (GUI) libraries must be included, so there's a definite need for conditional compilation via #ifdef
on many Linux distributions, a tiny build of Vim serves as the default implementation for vi; that one should not have any of the extended features
it allows for utter flexibility: developers / packagers can mix and match freely (though I guess most will stick to the default tiny / big / huge feature bundles)
So, my (unofficial) guess is that a useful and necessary (see above) feature was increasingly used for more and more features as Vim grew and matured. Initially, this is good (consistency, a single mechanism to configure). When problems started to appear, it was too late to retroactively switch to a (better?) approach (like runtime configuration); the (development and testing) effort would now be prohibitive.

Optimising cross platform build system

I'm looking for a cross platform build system for C which helps to find good compiler flags on a specific machine. It would need some notions of testing for correctness, benchmarking for performance and multiple versioning of the target, and perhaps even recognising the machine it is running on. For example, in a typical build I'd want to compare 64 bit versus 32 bit executables, with and without openmp, fast-math, with different optimisation levels, and builds by entirely different compilers. The atlas-blas libraries are an impressive example here but are a bit of a pain on windows due the shell scripting. Is this something that can be hacked onto systems like Scons or Waf? Any other suggestions?
Other than the one I'm thinking about writing when I'm done procrastinating, Boost Jam (bjam) would probably match your description closest.
There is also CMake, but I think it would require a scripting layer to automate multi-target building and testing.

How would I go about creating my own VM?

I'm wondering how to create a minimal virtual machine that'll be modeled after the Intel 16 bit system. This would be my first actual C project, most of my code is 100 lines or less, but I have the core fundamentals down, read K&R, and understand how things ought to work, so this pretty much is a test of wits.
Could anyone guide me in as far as documentation, tools, tutorials, or plain old tips/pointers on how to go about this, thus far I understand that I require somewhere to store data, a CPU of sorts and some sort of mechanism that functions as an interrupt controller.
I'm doing this to learn: Systems internals, ASM internals and C - three facets of computing that I want to learn in a singular project.
Please be kind enough not to tell me to do something simpler - that would only be annoying. :)
Thanks for reading, and hopefully writing!
Virtual machines fall into two categories: those that interpret the code instruction at a time and those that compile the code to native instructions (e.g. "JIT").
The interpretation category is usually built around an instruction execution loop, using a switch statement, computed gotos or function pointers to determine how to execute each instruction.
There is a fun platform that is worth studying for its simplicity and fun: Corewars.
Corewars is a programming challenge game where programs written in "Redcode" run on a MARS VM. There are many MARS VMs, typically written in C.
It has also inspired 8086-based versions, where programs written in 8086 assembler battle.
Well, for starters I would pick up a reference book for assembly language for the processor you intend to virtualize, like 80286 or similar.
For a JIT, you might want to dynamically generate and execute x86 code.
If you want to write a Virtual Machine using the x86 VMM technology you will need quite a bit of things.
There are a few instructions that are critical such as VM_ENTER/VM_EXIT (name can change depending on the chip, AMD and INTEL use different names but the functionalities are the same). Those instructions are actually privileged and therefore, you will need to write a kernel module to use them.
The first step for your VM to start is to boot it and therefore, you will need a 'BIOS' which will be loaded. Then you need to emulate devices, etc. You could even run an old version of MSDOS in such a VM if you wanted to.
All in all, it clearly isn't trivial and requires a lot of time and effort.
Now, you could do something similar to what VMWare used to do before the Virtualization ready CPUs appeared.

Resources