I did the same (4-bit cpu, 11 instructions) in my Microprocessors class, out of 74-series logic, one GAL20V8 to handle the SLE instruction and an EPROM (not an EEPROM - one with the clear window you exposed to UV light to erase.
That was also where I learned about ground-bounce & dynamic IR-drop effects due to those long looping wires between breadboards.
One hypothetical outcome if FTX had not been shut down when it was might have been "there was never a mass withdrawl of funds from FTX that would trigger an FTX liquidity crisis and Alemeda switched its strategy to 100% HODL, waited until exactly now before selling, thus making all the Alameda investors rich and covering the funds 'invested' by FTX so no harm, no foul".
Amother hypothetical outcome might have been "Alameda continued to make risky, over-leveraged investments, immediately rolling any gains into other over-leversged investments and using FTX's customer's money to cover losses until disaster struck".
I find the second hypothetical a bit more plausible than the first, but I probably just don't understand finance.
Ugh. Sudden flashbacks to having to switch analog output between Japanese NTSC (no pedestal) and US NTSC (with pedestal) without getting weird noise in the black regions.
But IIRC the MPEG-2 standard had luma==235 -> 100IRE for all of the analog formats (pal/ntsc-j/ntsc/secam) so I'm not sure why you say that would violate the broadcast limits?
Why don't you? It's open source. No one is stopping you. Your ideas on how init systems should work are obviously superior, so you'll easily win over a majority of developers, right?
I read the page and went through the "verify the cycles for yourself" sequence and I still have no earthly idea when defining the cycles, what is the rule that says "if you're currently on hexagram X, you can calculate the next hexagram Y by doing..."
"Happiness comes in small doses folks. It's a cigarette butt, or a chocolate chip cookie or a five second orgasm. You come, you smoke the butt you eat the cookie you go to sleep wake up and go back to f---ing work the next morning, THAT'S IT! End of f---ing list!"
Not to go all Ian Malcolm, but half this comment section is spending so much time wondering if we could build a space data center, without stopping to ask if it made any goddamn sense whatsoever to do so.
Heat travels when there is a thermal gradient. What thermally superconducting material are you going to make your cube out of that the surface temperature is exactly the same as the core temperature? If you don't have one, then to keep the h100 at 70c, the radiators have to be colder. How much more radiator area do you need then?
Have you considered the effects of insolation? Sunlight heats things too.
How efficient is your power supply and how much waste heat is generated delivering 1kW you your h100?
How do you move data between the ground and your satellite? How much power does that take?
If it's in LEO, how many thermal cycles can your h100 survive? If it's not in LEO, go back to the previous question and add an order of magnitude.
I could go on, but honestly those details - while individually solvable - don't matter because there is no world where you would not be better off taking the exact same h100 and installing it somewhere on the ground instead
"Just shift back" is really underestimating how much effort it takes to port a design to a different foundry. Sure, you can target a new stdcell library and recompile your RTL (and re-floorplan, and re-do a bunch of other stuff) but you also have to swap out all your memories and interfaces, not all of which may have exact equivalents... it can easily take 1+ years of work for a competent team, and if you have to shift back all that time and effort was wasted.
Some of us are old enough to remember the last time Intel was definitely, 100%, for-sure committed to offering foundry services, and then changed their mind and canceled the whole thing (it was in 2018) and want to see (a) someone else have success with 18A first and (b) intel show an actual long-term commitment to using their foundry for outside customers before we risk our companies' future on them.
There are risks with TSMC, but "TSMC just decides it's not interested in making chips for other people, and cancels the whole business" isn't one of them. The same cannot be said for Intel.
Big-endian matches the way we commonly write numbers, but if you have to deal with multiple word widths or greater than word-width math I find little-endian much more straightforward because LE has the invariant that bit value = 2^bit_index and byte value = 2^(8byte_index).
E.g. a 1 in bit 7 on a LE system always represnts 2^7 for 8/16/32/64/ whatever bit word widths.
This is emphatically not true in BE systems and as evidence I offer that IBM (natively BE), MIPS natively BE) and ARM (natively LE but with a BE mode) all have different mappings of bit and byte indices/lanes in larger word widths* while all LE systems assign the bit/byte lanes the same way.
Using the bit 7 example
- IBM 8-bit: bit 7 is in byte 0 and equal to 2^0
- IBM 16-bit: bit 7 is in byte o and equal to 2^8
- IBM 32-bit: bit 7 is in byte 0 and equal to 2^25
‐ MIPS 16-bit: bit 7 is in byte 1 and equal to 2^7
- MIPS 32-bit: bit 7 is in byte 3 and is equal to 2^7
- ARM 32-bit BE: bit 7 is in byte 0 and is equal to 2^31
Vs. every single LE system, regardless of word width
- bit N is in byte (N//8) and is equal to 2^N
(And of course none of these match how ethernet orders bits/bytes, but that's a different topic)
That's correct, the Romans had March as the first month of the year, so leap day was the last day of the year and September, October, November and December were the 7th (sept), 8th (oct), ninth (nov) and 10th (dec) months.
That was also where I learned about ground-bounce & dynamic IR-drop effects due to those long looping wires between breadboards.
That was a fun class.