Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
byuu
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
115 ms
·
901.
▲
by
byuu
15y ago
I can agree with that. I'm sure you weren't implying me in particular, but to clarify, I certainly don't think open source is the solution to everything. I just find it particularly important in the field of emulation. This is much like a s
902.
▲
by
byuu
15y ago
Documentation is great in that it can elaborate in much more detail, especially with actual pictures and graphs. However, unlike source code, documentation cannot be machine tested for correctness. Honestly, they're both important, and for
903.
▲
by
byuu
15y ago
The main magic I do for RISC CPUs is allowing a write callback binding to the registers (overloading operator=) This allows us to handle pipeline invalidation on writes to the PC register, without having to special case the hell out of ever
904.
▲
by
byuu
15y ago
Oh, good. I was intentionally vague there, as I wasn't sure how much was public knowledge. Yes, basically we bypassed the JP (jump) and RT (return) opcodes, so that the program counter always stepped by one. Externally clock the CPU to move
905.
▲
by
byuu
15y ago
At launch, this cartridge had a retail price in Japan of ¥14,900. Which is $184USD today, or roughly $120USD in 1995 when it came out.
906.
▲
by
byuu
15y ago
I suppose it could allocate an extra byte anyway, and set that byte to null. It seems like that could cause issues with memory alignment if you go thinking every string is 256-bytes, but it's 257-bytes because of that. Not that big of a dea
907.
▲
by
byuu
15y ago
I figured the actual length value may be useful without needing pointer arithmetic, but this is a nice solution to the argument taking the size, and the return being the length (size-1, eg p[return]=NUL location.) I'll consider this idea an
908.
▲
by
byuu
15y ago
Well, Go code will eventually call into OS-level functions. And when your Linux kernel is built in C, the eventual calls to open(), etc will need null-terminated strings. So you will have to make a copy, eg std::string::c_str().
909.
▲
by
byuu
15y ago
Thanks, I will make the necessary corrections shortly. The strncat() behavior is quite confusing. I can understand expecting the buffer to already be null-padded and skipping that step, but always null-terminating the result seems to go aga
910.
▲
by
byuu
15y ago
Oh neat, thanks for posting this. I should note that I usually write articles to kick off discussions on my own forum, and then revise them after all input is gathered. They almost never appear on other sites, especially pre-revision. I'm n