Hello and welcome to C++ Weekly.
I'm your host, Jason Turner.
I'm available for code reviews, contracting,
and on site training.
Now in this episode, I am going to talk about the C++ Box
Project that I have been working on.
And it is available here on GitHub.
And as you can see, I have a very exciting website
at the moment, with only a little bit of a readme
and currently some failing continuous integration
test and code coverage and code factors that could be improved.
This is definitely a work in progress.
I have done a previous episode on C++ Weekly about this called
"Compile Time ARM Emulator," I believe was the title of that
episode.
And I have mentioned this project in my applied best
practices talk that I gave at CppCon 2018.
So this is an ARMv4 emulator that has been written in C++,
and it is 100% pure portable C++.
Although as you can see, I do have some failing test
at the moment.
I need to get that figured out.
But that's something that I can probably get figured out
pretty quickly here.
As you can see, this is not meant
to be a terribly formal episode about this project announcement
today.
But I wanted to draw some attention to it
because I'm going to be using it in some upcoming episodes
for just some programming in C++ kind of episodes.
So this is what the C++ box actually looks like
at the moment.
And this is running in Linux, but the project
is meant to be 100% portable.
It can work with compiler back ends
and whatever that exist from the LOVM playing project
on all operating systems.
And I'm using a cross platform GUI toolkit
for this and everything.
So right now I have this screen that has this one cyan
pixel on it right here.
And you can see I'm currently emulating at something
like it says 30 megahertz.
That's a really rough estimate.
That's actually meant to represent
30 million instructions per second, which in this ARM
emulator is probably a little bit closer to about 120
megahertz at the moment.
But I have the emulator paused.
And I'm going to just walk through a little bit of what
the whole goal of this project is.
First of all, there is some possibility for using this
as a teaching tool.
This is still a little bit TBD on this stuff.
So I'm going to hide that window away for the moment.
But what I have here is an emulated ARM, right?
So you can pull up the state of the machine.
You can see the state of all the current registers.
You can see the state of memory and of the current source
code that's being executed.
I have this current little sample project up
that defines an RGBA struct.
It defines display, ability to write pixels, set resolution.
Now let's set resolution of this tiny little emulated screen.
I'll get to that more in a moment.
And so I have this couple of dozen lines or so
of helper functions.
And then I've got my main.
And my main down here says I want to create
a display that is 16 by 16.
Then I want to write a single pixel in the middle of it
that is 100% red, 0% green, 100% blue, and 100% opaque.
So I'm going to go ahead and hit the Run button here.
Now, with it running, what it's doing is
it's basically constantly stepping through the project.
So I am going to add something here to this.
Because right now, it's going to execute through the project.
And then it is going to just exit basically.
The emulator is going into a halted state.
So I'm going to put in a loop here that
keeps it inside the emulator.
And maybe we can play around a little bit
and see what it's doing.
So each time you see that fuzziness there, you can see it
as basically rebooting.
So if I were to hit Pause, it's in run mode.
I'm going to reset it.
And now with it reset, we can see line 41 as highlighted,
I'm going to step in.
And it's stepping in here to this set resolution code.
And it is setting--
actually writing memory locations in the emulated CPU
that are controlling the width and height of the screen.
So you can see the width was just set,
and then we're going to step a couple more lines.
And the height will come in here.
And now this is the 16 by 16 that we wanted.
And then we execute a couple more lines.
And we see that the cyan here is now being drawn to the screen.
And as you can see, it definitely
has some work to do as far as trying
to get the exact alignment with the current source line being
executed and that kind of thing all working.
And I just wanted to share this project
that I'm currently working on.
So let's see if we can do something maybe a little bit
more interesting here.
Now, this inspired by compiler explorer
is constantly executing.
So I'm going to put this in run mode.
And so the project here has this pixel.
And it's basically constantly writing this same pixel
over and over again to the screen.
So now I should be drawing a line that
goes halfway across the screen.
And there it goes.
The line is halfway across the screen.
And we can see this is kind of executing this while
true loop over and over and over again here.
And we can see which part of the memory
is currently being executed.
And we can see if any registers are changing.
And right now, only the program counter is changing.
And that makes sense, because it's just
writing the same thing over and over again here.
And we could make this slightly more interesting perhaps.
Make it draw across the screen.
Make the current x location come into the color component
of this.
So we're going to get something of a varying
color across the screen.
And right now I have a compile error.
And I don't have the ability yet to actually show that,
but that's currently in progress.
So I have a compile error because this RGBA is expecting
[INAUDIBLE],, and I just passed it an integer.
So I can do something like that.
And now I should get a color that changes across the screen.
But changing just by a value of eight,
this is not something we can really see on here.
So that is the green component.
Let's make that x times say 4, and see if we can start
to see some color variation.
But we can see it reboot and execute the new code
as we're typing along.
And we're still not really seeing anything to speak of.
There we go.
So with a scale of 16, now this goes from magenta to white.
I think I said cyan earlier.
So there you go.
The entire point of this is to make a C++ environment that is
fun and easy to work with.
Obvious things that need to change,
we need to get the display into some sort of dockable ball
so that there's not just a bunch of windows to shuffle around.
I need to do better disassembly and debug
tracking so that the current location being executed
is better represented.
And I need to display what errors and warnings there are,
maybe syntax highlight those things in the editor
to let you know where the errors and warnings are.
And the learning component of it,
these goals up here that are currently hidden away,
that needs a lot of work.
But it's an idea and a work in progress.
So throw this out there.
If anyone's interested in a project like this
and contributing to it or anything like that,
feel free to check it out.
It's on GitHub, as I already showed.
And I've attempted to make a bunch of issues
that are in the user friendly first time programmer, kind
of first time contributor to this project tagged
that way in the issues tracker in GitHub.
So check it out, and like I said,
expect to see this come up more in future episodes.