Tag Archive : cross-platform

/ cross-platform

Mixing C++ with AMD64 (x86_64) assembly

9 November 2019 | asm, C++, cmake | No Comments

Lately, I’ve been dabbling into some “closer to the metal” kind of programming.

On most compilers (Visual Studio’s one for instance) it used to be rather easy to mix assembly code and C++ code using a feature called inline assembly where the ASM code will be put in a block (decorated with a special macro/symbol like _asm for instance), and when the compiler sees that, it will put the content of this “as is” inside of the compiled code.

Well, that feature don’t exist once you compile in 64bit mode, and also, mixing programming languages in a single file is a bit gross. Each time I see this, I think it feel rather ugly…

Instead, it would be good to separate that code into files, that will be assembled into object code you can link to your program as you do with C++ compilation units and static libraries…

So, how do you go about doing this, and doing it in a simple, and cross platform manner.

Well, first of all, there’s 2 things to consider when writing code in assembly.

1) The code you write obviously depend on the machine instruction set, since you are basically asking a CPU to do work, but you do it *instruction per instruction*. This means that you can only target one family of processors with that code. So when I say cross platform, I mean different rutnime on compatible machines. For example Windows VS Linux VS MacOs running on good old Intel (or compatible) chips.

2) Generally, you don’t just write instructions when writing assembly, you also write directive for the program that turn your code from human readable thing with letters and spaces and comments into the digital gibberish the CPU actually eats up to work. And there are multiple of them, and they aren’t really compatible with each other.

I was on a windows machine when I started experimenting, and saw that there was obviously the MASM option, the macro assembler from Microsoft that was already installed on my box, as it is distributed with Visual Studio. Great… And I started playing with it, it’s not hard. I even got CMake to generate automatically a build system that work. But sadly these effort were vain as I quickly released that, I would not be able to use Microsoft’s assembler on Linux or a Mac for quite obvious reasons

So, as always… Open-Source software win the day!

I was working on something totally unrelated that involved me having to build from source the OpenSSL library. When looking at the dependencies I needed to install on a bog standard windows box to do so, beside their horrendous build system written in Perl, one program stood up: NASM.

NASM is, my friend Google told me, the Netwide Assembler. It’s a BSD licensed Open-Source macro-assembler for 16, 32 and 64bit intel chips! Great news! It is cross platform and work on Linux and MacOS too (and I bet a bit more stuff!)

Also, I started googling around to see if CMake could auto-magically handle it, and indeed it does since a prehistoric version.

So, I got around to test that, and well, beside a tiny snag on MacOS that is apparently due to the way MachO object files differ from ELF files (a sad story of respecting standards about leading underscores) that is quickly fixed by telling NASM to prefix all global symbols with a _ character, I got a thing that just worked.

So, the result of this silly experiment is a demonstration repository that has nothing impressive to show beside how easy it works. It’s here, there’s C++ code, there’s ASM code, there’s a CMake project file that compiles everything together, the C++ code declare some extern "C" functions with names and interfaces that just happen to match the globally defined exportable symbols in the assembly code, and… voilà!

https://github.com/Ybalrid/cmake-cpp-nasm

Feel free to steal the literal 4 lines of configuration needed for this thing to work and go do some cool stuff! 😀

SDL: not (just) a 2D graphics library

3 September 2019 | C++, cross platform, SDL | No Comments

SDL logo

My first real introduction with programming was with the C programming language, on a French website that was, at the time, known by the “Le Site Du Zéro” (think “The newbie’s website”).

At this time, I was in middle school, and I was pretty bored by it. It’s around that time that I started to have really access to the internet at home, and started spending a lot of time on it.

There were a few things behind this, mostly I was looking for trying to understand how video games works and how they were made. I was also trying to learn more about how computers work, without actually knowing what to look for, and I started dabbling into Linux in that time. This was around 2007.

This website had a well written, comprehensive, and actually fun “Introduction to C programming” tutorial. (They called them tutorials, but think of them more like courses…) Today, this website became “Open Classrooms”, a popular french MOOC platform, but the originals “tutos” are still up, and were (for some of them) improved, some turned into video courses.

This one was divided into 3 parts, one that is you “C programming 101” type of stuff, were they show you how to create variables, functions, if statements, loops, structures… This kind of things, the 2nd one is about more advanced things with pointers, memory allocations, arrays and whatnot, and the 3rd one is about showing you how to use a library, and takes example of the SDL to create a window, display things, and make a little sokoban game (with stolen Super Mario World sprites 😉).

In this thing, SDL is described as being a 2D graphics library for games, and for years, I regarded the SDL as being just that. I have no clue if other people had this misconception, but when I look for things about the SDL, I mostly see things about making 2D games with it, or seeing it merely as a way to get a window and a screen and not much else.

But, oh man. It’s so much more than that.

The SDL name did make little sense to me at that time, but I never really thought about it. SDL is the Simple Directmedia Layer. A better way of describing the SDL would be a “cross platform API for doing most of the things you would want to do with an OS, including drawing windows, creating threads, loading DLLs, and pretty much anything.

I’ve learned recently that it was developed to be used as an aid for porting software from windows to other platform. The main idea being to support functionalities in a convenient package that are analogue to what was available with Microsoft DirectX. This was developed by former Loki Software employee Sam Lantinga. The business-model of that company was to port video games from windows to other platforms, and mostly Linux.

The SDL works on pretty much anything you would want to use. Today, for me it looks more like a fundamental building block for multimedia programs (video games, and other interactive things with custom graphics), and without having to worry too much about the platform you are running into.

If you use the SDL, anything you do through it will work on a computer running Windows, MacOS, Linux, flavors of BSD, obscure little things like Haiku (Haiku is awesome. This is a really interesting operating system project), any kind of smartphone being Android or iOs, and probably much more things like video game consoles. All these platforms are available to you without having to change your code too much (not at all most of the time).

Since version 2.0 came out, the SDL is licensed under the zLib license. Before that, SDL was LGPL. LGPL is not a problem in commercial, closed source software (like video games usually are) when the library is dynamically linked to the program (for example, on Windows, the library is a .DLL file distributed alongside the binaries of the game.) This permit you to recompile and change the library, and the developers of the game needs to make the source code of the version used with the game available to you, including any changes they may have done to it, and under the same rights. This can make some company’s lawyers uneasy. the zLib license is a much shorter, much straightforward license that pretty much says “do whatever with the code of this, and credit about it is appreciated”

Also since version 2.0, the huge feature list of the library was expended further. The impressive feature list can be read here.

I spent quite some time misrepresenting what the SDL was, thinking that it was just a lousy 2D graphics libraries with a software renderer, and not the impressive tool that it actually is.

Few years ago, while searching content from Vavle about their SteamVR system, I stumbled across this talk by Ryan C. Gordon, a prolific freelance programmer that, if you ever ran a video game natively on Linux, there’s a pretty high chance he helped make this a reality. I really invite you to watch this, and appreciate all the hard work this simple C library can do for you in just a few lines…

As a side note, I really should plug a little project a good friend of mine started some time ago (and which I contribute to, because it’s awesome) to make a safe, C++17, RAII wrapper around most of the useful bits of SDL for 2D/OpenGL/Vulkan programming. Check it out here: https://github.com/Edhebi/cpp-sdl2