Comment by userbinator | Hacker News Reader

Comment by userbinator | Hacker News Reader

After seeing C4[1], everything else doesn't seem tiny at all... and maybe it's just me, but this is another one of those projects where I found the directory layout rather confusing, especially for something that claims to be "small and easy to understand." bin/ is empty, there's only a single nearly-empty file in src/, lib/ is also empty, include/tvm is two levels but one is empty, and all the interesting stuff actually appears to be in libtvm/ .

More importantly, even after going through all the files in libtvm/ , I still haven't managed to find the main instruction execution loop nor the decoding switch. Sorry, but I don't think "small and easy to understand" applies, and I've had experience with VMs and interpreters and the like for many years. Compare with this, for example:

https://github.com/tjmerritt/z80

A rule-of-thumb when investigating the source code of a project for the first time: if I have to go more than 2 directories deep to get to the "meat" of the code, my desire to explore further drops significantly.

[1] https://news.ycombinator.com/item?id=8558822

C library public headers are commonly two levels deep to so that projects using them can add the "include" directory to their header search path and in their code have #include "<libname>/header.h". It helps avoid filename clashes.

I dunno, I find it pretty easy to understand... seems like the main instruction loop is in tvm.c, in the function tvm_vm_run(), which is exactly the first place I looked and seems totally sensible to me.

  for (; vm->prog->instr[*instr_idx] != -0x1; ++(*instr_idx))
    tvm_step(vm, instr_idx);

Compare that to my 6809 emulator [1]. I have a mc6809_run() function that is pretty much the same, but mc6809_step() is in the same file and not hidden in a header file. There also seems to be a lack of memory operations (like reading or writing) other than PUSH/POP.

[1] https://github.com/spc476/mc6809 [2]

[2] Yes, it lacks a README. I know.

>bin/ is empty, there's only a single nearly-empty file in src/

Because that's where the generated binary will go.

>lib/ is also empty

Presumably the same for any lib files?

>include/tvm is two levels but one is empty

That's as intended too, poor man's namespacing.

> Because that's where the generated binary will go. > Presumably the same for any lib files?

Why is even tracked, then? Surely putting it in .gitignore is a better way to go?

I find leaving them in the repo makes it pretty clear how your have to configure your build process. For GCC, I instantly know I need `-I ./tinyvm/include/` and can use `#include <tvm/tvm.h>` etc.

I’ve found that switch fast, in a few clicks, reading this on my phone:

https://github.com/jakogut/tinyvm/blob/master/include/tvm/tv...

I’ve used the info you provided as the start, of course.

In a .h file?

Have to agree with userbinator.

Isn't it odd to have:

/* nop */ case 0x0

Rather than #define NOP 0x0? Namespacing? How about vm_NOP?

"easy to understand" is added by the poster to the title, the repo doesn't make this claim.

With zero explanation and code it's small experiment, but not really educational.

By C4 you meant C in 4 functions? https://github.com/rswier/c4 here?

Why does he/she have .gitignore files in subdirectories? That seems to make those subdirectories linger for no reason.

Usually because a build script depends on their existence or something.

Then have the scripts create them?

>Why does he/she have .gitignore files in subdirectories? That seems to make those subdirectories linger for no reason.

He has it precisely to make them linger. And what "no reason"? It's so subsequent scripts can put results there.

Better form to just have those scripts create the directories.

Sure, but it's not like why having them persist is a mystery, or hurts understanding the structure of the repo, as the parent claimed.

That's not even what was claimed. http://www.dictionary.com/browse/rhetorical-question

Reply on news.ycombinator.com