Notices by poleguy (poleguy@mastodon.social)

@whitequark "ceremony..." that resonates. Well, I appreciate you humoring my line of inquisition as far as we took it. It reaffirmed my sense that it was not a route likely to pay off with any practical value.

@whitequark I feel a bit sad that gdb is seemingly ossified so hard that spinning up a new architecture/ language/ machine code is essentially harder than reinventing everything from scratch. But if someone like you won't even endorse it, it is not worth pursuing even as a personal challenge. My youthful idealism is dashed. :-(

@whitequark yes. I implemented a step debugger, breakpoints and memory inspection when we designed the processor originally. In reality the code is all real time dsp, so debugging is mostly done in rtl/cocotb sim where we just spit out a trace file based on watching a variable and/or program counter. Or we do it in hardware using telemetry over a gigabit serial link where we can stream out whatever state we need to monitor. Or we use one channel of the audio output to monitor an internal node.

@whitequark done.

@whitequark This does not surprise me. But in my previous attempt I could not find even a basic list of steps like this.

I can disassemble/write the machine code. But I don't know how to do so "for gdb".

We do not use elf. The code is just a binary file with machine code that gets loaded into an FPGA RAM.

We have not written a compiler. Everything is written in assembly. I would aim for assembly level debug only. I wonder if this makes it easier or harder.

Tedious/thankless sounds right.

@whitequark You mean there isn't a hello world? If so, that makes me feel good that I didn't just fail to find it. :-)

I probably don't have the terminology right. What does it mean to "have gdb" for my "DSP target"?

I presume the steps look something like write some code on the PC that translates between what gdb needs to work and what my serial-cli can provide. (?!).

This is a custom FPGA, I presume there is also some sort of definition for my architecture/assembly/machine code needed?

@whitequark I'm not confident I know exactly which pieces you've been working on here. But I have dreamed to do something like this for a custom DSP inside an FPGA at work. I'm not afraid of getting my hands dirty. But the last time I tried to find the "hello-world tutorial" for connecting gdb to an arbitrary device I didn't get very far. I'd love to connect it via our existing cli/debug interface (serial-usb). I've implemented everything needed to do step debugging in the hdl, but no gdb yet.

@whitequark just today I wished I could open vivado from my other machine. But what I really wanted was to connect to the session that was already open. I ended up walking out to the lab. I actually have an x2go session open with vivado as well, but x2go doesn't do a good job sharing the local desktop when you have many physical monitors hooked up. And it really doesn't like the Dvorak keyboard layout. I hadn't thought of steam.

@whitequark I just use typer. Good enough.

@artlung @mattl that's more than somewhat off. Yikes that is disturbing quantization.

@koz @dalias can't try ppa/deb AppImage or snap on your distribution?

@koz @dalias Yes. I try to avoid non native installs. I don't think they provide much value for the end user and they always add pain points.

@dansup I don't get an email when I sign up. I don't get any error messages. I try to login and it stays on the login page.

@lzg

Maybe a ceramic mandoline slicer?
https://cutlery.kyocera.com/soft-grip-ceramic-mandoline-slicer

@arstechnica I love that anything bad is always found on "the dark web". Yet I doubt anybody buying from this tor site got there by looking for "the dark web" to find it. They just clicked on links and followed the instructions just like doing anything on the bright web.

@fuat2mb It seems some people don't understand that virginity involves a directional component: the things coming out don't have the same behavior as the things going in. :-)