begin actually setting up the repository as a GMod addon..

This commit is contained in:
Lily Tsuru 2023-07-16 06:05:19 -04:00
parent b4a343e9db
commit 1d14a89fb7
8 changed files with 24 additions and 14 deletions

0
data/.gitkeep Normal file
View File

View File

@ -1,17 +1,23 @@
- cpu cores - cpu entities
- controllable paramaters (ram size, ...) - controllable paramaters (ram size, ...)
- admin controlled per-user max RAM size (default 16mb) - admin controlled per-user max RAM size (default 32mb)
- possibly override for "respectful" users and admins? - possibly override for "respectful" users and admins (admins probably wouldn't even count)?
- admin controlled per-user max lcpu chip count (default 4) - admin controlled per-user max lcpu chip count (default 8)
- admins can override? - admins can override/do not count?
- admin controled global (affects all placed lcpus) scheduler timeslice (? cpus wouldn't block source anyways, the only way they could is if they start posting too many cpu thread -> lua thread callbacks ?)
- admin controled global (affects all placed lcpus) scheduler timeslice.
- couldn't be faster than tickrate though or we might block source (and.. well, i dont think i have to explain)
- upload a raw binary (or elf? we could probably just imitate a "boot loader" and throw it into memory and move the given register to it?) to execute - upload a raw binary (or elf? we could probably just imitate a "boot loader" and throw it into memory and move the given register to it?) to execute
- or write code as a "lcpu project." in theory exporting out to a Makefile/etc should be possible - or write assembly/maybe c code for tiny projects
- text editor for lcpu projects - text editor for lcpu projects
- supported architechures (iniitally. more could be added and a "common" abstraction framework for devices could be agreed on) - some example projects?
- riscv rv32-ima cpu core - riscv rv32-ima cpu core
- llvm assembler/maybe clang integration? (this might make the addon unwieldly though) - llvm assembler used in this case
- maybe clang integration? (this might make the addon unwieldly though)
- wiremod interopability (to obsolete ZCPU at least for my purposes) - wiremod interopability (to obsolete ZCPU at least for my purposes)
- gpio (which uses normal wire stuff) - gpio (which uses normal wire stuff)

View File

@ -0,0 +1,4 @@
-- skeleton load file to get gmod to recognize this as an addon
-- this will contain files later on in life.
print("hello world?")

View File

@ -68,6 +68,6 @@ namespace lucore::detail {
} // namespace lucore::detail } // namespace lucore::detail
namespace lucore { namespace lucore {
using detail::NullRef; using detail::NullRef; // NOLINT ..yes, yes they are used. why do you think they aren't.
using detail::OptionalRef; using detail::OptionalRef; // NOLINT ... ditto!!!
} // namespace lucore } // namespace lucore

View File

@ -6,8 +6,8 @@
namespace lucore { namespace lucore {
[[noreturn]] void ExitMsg(const char* fileName, int fileLine, const char* message) { [[noreturn]] void ExitMsg(const char* fileName, int fileLine, const char* message) {
// TODO: move this to logger functionality of lucore (gmsv_lcpu will end up containing a // TODO: move this to logger functionality of lucore (the native module will end up
// Sink impl..) // containing a Sink implementation that funnels to either gmod or tier libs..)
std::puts(message); std::puts(message);
std::quick_exit(0xAF); std::quick_exit(0xAF);
} }