@requiem I'm assuming you're rewriting the pvm interpreter in C?

Also, for the 8-bit targets, there are several options I think. For the 6502, there is cc65 or Calypsi, which @mos_8502 brought to my attention recently. For Z80, some traffic on the RC2014 mailing list indicates people have gotten the CP/M HiTech C compiler working. Its dialect predates C89 though, IIRC.

@akkartik @neauoire @z OMG, that is the most cursed Python repository I've ever seen.

@kototama @ekaitz_zarraga C is a lot more complex than Forth or Lisp. In the amount of space you invest in just the C lexer and parser alone, you can fit an entire Forth compiler capable of reaching within a factor of 10 performance of native, optimized C.

The only reason I don't want to run a server at home is because (1) everybody else in the market has literally made it impossible to do without spending unacceptable amounts of time administering resources, and (2) spammers/script-kiddies who find exploits in every little fucking nook and crannie.

I actually DO want to self-host all of my resources. I just don't want to spend a career's worth of talent (especially at my age) doing it.

Home-made semiconductor fabrication techniques are getting more sophisticated. From the hacker who put 6 transistors on a chip in an amplifier configuration, behold, one thousand two hundred transistors.

https://www.youtube.com/watch?v=IS5ycm7VfXg

(Admittedly, not configured as anything in particular yet, but the work is getting there. He's already half-way to an Intel 4004. I'm willing to bet that you can make a viable CPU with 1200 transistors if it used a bit-serial micro-architecture.)

Blog article is here: http://sam.zeloof.xyz/second-ic/

@theruran Yup. Remember all the nay-sayers saying this wasn't going to be possible? Because, I sure do.

The equipment that he's using is not exactly the kind of thing you'd find at Home Depot though. He's got a fair bit of cash invested in his garage fab. Still, making chips at home. That's ... downright awesome.

@ekaitz_zarraga Implementing a singleton?

@ekaitz_zarraga If this happened, I'll have missed the stream. Will it be recorded? I'd love to watch the video afterwards.

I'd much rather be streaming me coding in Z80 assembly language right about now. Sigh.

Always known that commercial FPGA/ASIC developer tools are, well, shit. Like, this stuff is irreparably bad.

But, the extent to which Synopsis and Cadence tools suck can best be summarized as threatening to civilization itself. The time dilation engineers go through when working with these pieces of shit is so extensive that they'd make ideal case studies for black hole research.

"Oh, I'll just get this design working on the simulation environment, and, holy shit, it's already next week! What the fuck just happened?!"

I haven't even finished this week out, and I'm already so fucking done working with this bullshit.

I really wish I had the economic freedom to demand, "Give me Yosys and Verilator, or give me a pink slip."

@ekaitz_zarraga Concerning long literals, what I've done in the past is to maintain two buffers, one for constants, and one for code. When emitting the code, I'd then spit out both buffers, one after the other (order doesn't usually matter). That way, a single AUIPC can be used and constants can be referenced using larger offsets.

One thing to make sure of though: make sure your constants are 64-bit aligned. I didn't see reference to this in your article. I know that RV64GC Linux ABI supports non-aligned references, but not all RISC-V environments do.

#riscv RISC-V bit manipulation extensions are finally public and are open for public comment.

https://github.com/riscv/riscv-bitmanip/releases/tag/1.0.0

@ekaitz_zarraga OMG.

OMG. Are you ready for this?

I can't stop laughing at this. I goofed hard.

The AUIPC instruction adds the value 0x28000+PC of the instruction, which in this case, happens to be at address 0x00008. So, A2 is loaded with 0x280008.

So the ADDI A2,A2,-8 instruction adjusts that to point A2 back at the desired value.

I'm still baffled why it didn't just use LUI in that case, but it at least does arrive at the right answer. It had me confused since this morning.

@ekaitz_zarraga

should expand to:

Instead, it expands to:

That's the wrong address. If this code is executed, the copy loop will use the wrong target address (it'll be off by 8 bytes in this case).

@ekaitz_zarraga So, here's the thing.

If I come up with a simpler example, the bias changes. Or the linker does something different altogether. This is a bug which seems extremely sensitive to input conditions.

Here's a more complete replica of the code:

@ekaitz_zarraga Sorry; that needs to be auipc, not ld.

@ekaitz_zarraga If you pass -march=rv32i it will assemble for RV32. There are similar flags for ld.

@ekaitz_zarraga I'm relocating a chunk of ROM code into RAM (think, memcpy(rom_start, 0x28000, 0x8000) in C). It's a 32-bit processor, so no double-words. But, even if I just comment out the copy loop, the -8 bias remains. It makes no sense.

Calling all RISC-V developers using the GNU toolchain.

I have some code like this in a foo.S file:

.extern PGM_START # ...etc... la a2,PGM_START

In the sections.lds linker script (passed via the riscv64-unknown-elf-ld -T flag), PGM_START is set to an address:

PGM_START = 0x28000;

When I assemble foo.S, I see it is expanded to something like this:

ld a2,0x28 addi a2,a2,-8

Where is this -8 offset coming from? This appears to be a failure of GNU ld to apply a relaxation. Except for manually replacing la with auipc, how can I convince ld that there is no -8 bias to that symbol?

Boosts welcome. I'm desparate at this point.

Even text files are unsafe. Text files!

https://www.paulosyibelo.com/2021/04/this-man-thought-opening-txt-file-is.html