lefticus / cpp_box Goto Github PK

Currently two sample goals exist, this issue should be used to track a specific set of lessons that we might want to implement.

See here:

http://llvm.org/docs/LibFuzzer.html

https://clang.llvm.org/extra/clangd.html

See https://github.com/lefticus/cpp_box#architecture-documentation for specifics on the goals

Should at least start with a command line configuration. catch2::clara is already available for use, but other command line parser options could be considered.

Will be necessary for statics/globals

We'll prefer ChaiScript (for obvious reasons) for the scripting technology.

The current interface to the lessons / goals can be found here:

https://api.csswg.org/bikeshed/?force=1&url=https://raw.githubusercontent.com/vector-of-bool/pitchfork/spec/data/spec.bs

Currently each part of the opcode is decoded on demand, we should try doing this upfront when the opcode type is constructed to see if the reduced work done during actual processing of the instruction helps performance.

if it does we can build a better/smarter CPU cache.

Relies on #26

Basic ARM object files that are simple (terminating loops that exercise various instructions) so we can test performance of the CPU emulator

I've started the hardware design on the wiki https://github.com/lefticus/arm_thing/wiki/Memory-Map

Soliciting comments if you have any, @mattgodbolt and @jonathandturner

internal compiler error: in force_type_die, at dwarf2out.c:25955
         for (int i = 0; i < status.opsPerFrame && status.sys->operations_remaining(); ++i) { status.sys->next_operation(); }

g++ version:
g++ (Ubuntu 8.1.0-5ubuntu1~16.04) 8.1.0

User needs to have compiler output (warnings and errors) parsed and shown in the IDE.

I believe we need to look in the dynamic symbol table.

Consider using CMakeRC to package up the headers?

https://github.com/vector-of-bool/cmrc

Specifically we want this standalone header implementation of libcxx https://github.com/lefticus/libcxx

Currently the ELF loading capability is baked into the front-end cpp file and should be moved into another file/lib

Could be interesting to debugging of the system.

Minor: Displaying %s instead of Hint headers.
From the cpp_box.cpp: 641

if (ImGui::CollapsingHeader("%s", fmt::format("Show Hint #{}", clue).c_str())) { text(true, "{}", goal.hints[clue]); }

https://github.com/lefticus/arm_thing/blob/8da91d94ea79fac24118c646eca8d9e0102c51eb/include/arm_thing/arm.hpp#L24

Current UI is cumbersome, we need some way to have it better organized / dockable. The current experimental dockable branch on imgui should help https://github.com/ocornut/imgui/tree/docking

You can see here in codecov that the unit tests are only covering about 1/2 of the possible Data Processing instructions that the ARM supports.

https://codecov.io/gh/lefticus/cpp_box/src/master/include/cpp_box/arm.hpp#L725...742

You can see details about the instruction format and architecture supported in the README

The instructions to test can be generated by hand or with an ARM assembler or compiler (using objdump on an ARM object file can be quite revealing)

$ clang++ --target=armv4-linux -stdlib=libc++ -O3 some_file.cpp -o some_file.o
$ llvm-objdump --disassemble some_file.o

Tests are located here: https://github.com/lefticus/cpp_box/blob/master/test/constexpr_tests.cpp

There are a couple of important things to notice:

• We are using a macro so that the tests can be built in either constexpr or not. This is important for debugging. A constexpr build will simply fail to build if there is a problem, and this makes debugging the issue very difficult.
• The relaxed_constexpr_tests binary is built specifically for this reason, so we can test all aspects of the CPU as either constexpr or not
• Follow the patterns shown for how to enable a specific test for both constexpr and non-constexpr
• Do not limit yourself to just the catch2 directives I'm using - be as explicit and verbose with the test descriptions as you would like. (see also, for example https://github.com/catchorg/Catch2/blob/master/docs/test-cases-and-sections.md#top)
• Try to make the tests small, so it's possible to debug them more easily
• Consider what register values you need to set up. Consider adding a new overload to run that takes a set of pre-set register values if desired.
• Look at CMP test for a basic design https://github.com/lefticus/cpp_box/blob/master/test/constexpr_tests.cpp#L94-L101

Once you have made the PR we should be able to see the change in test coverage in the PR report on github.

Feel free to make multiple PRs as well, for different instruction tests.

Currently there are some functions that take a list of strings or paths and it's possible to swap up the order of parameters. Look for these cases and better utilize strongly typed wrappers to make mixing up params impossible.

They should result in a call to the unhandled opcode vector

Which should by default log / emit / somehow log that what the unhandled opcode was so it can be tracked and later implemented if it's a valid correct opcode.

Apple LLVM version 10.0.1 does not come with filesystem library header, resulting in an error on compilation. experimental/filesystem is also cannot be found.

Any workarounds?

Currently it's not possible to write assembly code directly. While it's possible to utilize inline assembly, it's just not very nice. I know this project is called cpp_box but an "Assembly" switch would be nice anyway. Especially if you plan any more videos like this one.

I will try to implement this myself because it seems relatively trivial, Clang can do all the heavy lifting for me. This is my working branch in a local fork: asynts/cpp_box.

Because of conan deps we aren't getting a clean built yet on LGTM

https://lgtm.com/

• Working Build
• PR Reviews Enabled
• Add badge to readme.

Can your program be used to investigate the real time behavior for cache line loads?

https://medium.com/software-design/why-software-developers-should-care-about-cpu-caches-8da04355bb8a

Currently main.cpp takes too long to compile.

Options include:

• breaking out arm.hpp so we don't compile the emulator each time
• breaking out fmt:: calls, they are heavy at compile time
• Upgrading {fmt}, newer versions should compile faster.