Ask Lemmy
A Fediverse community for open-ended, thought provoking questions
Rules: (interactive)
1) Be nice and; have fun
Doxxing, trolling, sealioning, racism, and toxicity are not welcomed in AskLemmy. Remember what your mother said: if you can't say something nice, don't say anything at all. In addition, the site-wide Lemmy.world terms of service also apply here. Please familiarize yourself with them
2) All posts must end with a '?'
This is sort of like Jeopardy. Please phrase all post titles in the form of a proper question ending with ?
3) No spam
Please do not flood the community with nonsense. Actual suspected spammers will be banned on site. No astroturfing.
4) NSFW is okay, within reason
Just remember to tag posts with either a content warning or a [NSFW] tag. Overtly sexual posts are not allowed, please direct them to either !asklemmyafterdark@lemmy.world or !asklemmynsfw@lemmynsfw.com.
NSFW comments should be restricted to posts tagged [NSFW].
5) This is not a support community.
It is not a place for 'how do I?', type questions.
If you have any questions regarding the site itself or would like to report a community, please direct them to Lemmy.world Support or email info@lemmy.world. For other questions check our partnered communities list, or use the search function.
Reminder: The terms of service apply here too.
Partnered Communities:
Logo design credit goes to: tubbadu
view the rest of the comments
If you need an expert on the long-discontinued Motorola 96002 digital signal processor, I'm your guy! I wrote an entire graphical operating system in its assembly language and still need to maintain it from time to time, so my skills remain sharp.
thats insane and really cool! what got you interested in that specifically?
Well we built some instrumentation around it at work back in the 90s and still use it today. It was ahead of its time. It had hardware loops, a hardware call stack, hardware circular buffer addressing, and a DMA controller. In one instruction, you could do 2 FPU operations and a memory move with a DMA transfer going on in the background. It was an insane architecture. And it could handle 3 separate memory spaces, so even though it's a 32-bit chip, you could access well over 4 GB of RAM.
The best thing about chips of that era though is you could tell ahead of time exactly how long your code will take to execute. Like you just type numbers into a spreadsheet and add up the instruction cycle counts. That kind of analysis is hopeless these days, but it informed the design of the instrument. More recently, we've been looking at RISC-V for a newer generation, but it's harder to predict ahead of time how it will perform?
I know how you feel, I once made the Kessler run in under twelve parsecs myself.
Whatcha coding that needs to be so precisely timed? Something nuclear? I heard once that nuclear plants have something called real time operating systems that allow for that type of timing prediction.
I can't say too much about it but we're in the mining sector.
And yeah, if I had to do it all over again from scratch, I'd definitely be looking at a real-time OS. There just weren't many options back in the day besides coding it all yourself. Even now, I'd have to benchmark the OS to see what its latency is actually like? We had it down in the microseconds range with our custom OS but if it's more like milliseconds with an off-the-shelf OS, for example, that would change the whole ball game.
super interesting read. thanks for your time!