|
That thing's gonna be completely useless anyway, for multiple reasons. Mainly, the weapon will always be pointing at *something* so it'll be endlessly flickering between light settings as long as the rangefinder is on. Which means our heroes, attempting to stealth their way around (since they apparently don't want their flashlights on until they have something to shoot) will actually be walking around with their own personal strobelights, helpfully guiding the enemy right to them.
|
#
?
Sep 8, 2018 22:07
|
|
|
|
| # ? Apr 29, 2024 10:49 |
|
|
It's for an infrared scope, there won't be any visible light.
|
|
#
?
Sep 8, 2018 22:18
|
|
|
Over priced and over designed, one project in and you're already an ace defense sub-contractor 
|
|
#
?
Sep 8, 2018 22:24
|
|
|
Want to save ¥1? If you drop the lower left chip 1 space then you can run the X0 from the upper left chip under itself to avoid using the bridge. Remember: Any component that is 3 wide lets you run a wire down the middle without interfering with it's operation. VVV Edit: I know, but it might help others who are trying to do similar projects save money. azsedcf fucked around with this message at 13:22 on Sep 10, 2018 |
|
#
?
Sep 9, 2018 08:44
|
|
|
azsedcf posted:Want to save ¥1? Quackles is likely fully aware of that. The "joke" is that he is making this design as expensive and overly complicated as possible because gently caress working for the Chinese military-industrial complex.
|
|
#
?
Sep 9, 2018 10:48
|
|
|
Something about this makes me want to write a short introduction to x86 assembly - I suspect a couple of people might find it interesting. The two main arguments against it is that a) it's nowhere near as easy to play around with, and b) it's been about a decade since the last time I seriously looked at it, and I'm rather rusty. It's an interesting family, though. The 8-bit ancestors (e.g. the 8008 and 8080) were not that much more capable than these MCPs, though they had more registers. The biggest instruction set difference is probably in the RAM - being able to use memory addresses directly in code is nice, and having the code reside in memory as well meant you could have a lot more of it. In comparison, contemporary amd64 has a baroquely overflowing selection of registers and instructions - consider AVX2, which gives you a bewildering selection of mathematical operations that work with 512-bit (!) registers, including some that treat them as arrays of 16 32-bit numbers and works on all of them in parallel. Another important difference is that the only people who write x86 assembly in a vacuum are motherboard firmware and BIOS/EFI developers. After all, nothing directly connected to the pins of a modern CPU is directly useful as an input or output device without a fair bit of initialization. The DOS days were somewhat similar, though: instead of writing a value directly to e.g. an LCD, you had a range of memory addresses that belonged to the graphics adapter, and could write values there to put text on the screen. The closest you can get on a modern system is probably on Linux (or a BSD), where you can print text to a console by having the appropriate values in your registers and prodding the kernel - or you can link your assembly with libc, and call on its functions to do it for you. (I honestly have no idea how you print to a windows terminal.)
|
|
#
?
Sep 11, 2018 17:08
|
|
|
Computer viking posted:The DOS days were somewhat similar, though: instead of writing a value directly to e.g. an LCD, you had a range of memory addresses that belonged to the graphics adapter, and could write values there to put text on the screen. The closest you can get on a modern system is probably on Linux (or a BSD), where you can print text to a console by having the appropriate values in your registers and prodding the kernel - or you can link your assembly with libc, and call on its functions to do it for you. (I honestly have no idea how you print to a windows terminal.) I hear that Racing the Beam is a good book to read if you want to know more about how old videogames got developed. ManxomeBromide's LP of Solaris also touches on the difficulties in getting things done on limited hardware. There's a lot of very careful cycle counting (like the tick counting in Shenzen I/O) involved if you want to do e.g. complex sprites on the Atari, because you have to drop new data into the right memory address on exactly the right cycle if you want the result to look visually correct.
|
|
#
?
Sep 11, 2018 17:25
|
|
|
Can You Keep a Secret?? Haunted Doll Project  You know how on Looney Toons, when a cartoon character blinks? And they have the tinkling of a xylophone to go along with it? That's about how I feel right now. After a while, you just sort of get... desensitized to bad ideas. You say to yourself, 'this is a bad idea', but... it is your job. All you can really do is be there to say "I told you so". Mind you, I'm looking forward to saying "I told you so" for THIS.    I tried to read the writing on that smeared chip, but without any success - so I'll have to settle for thinking of it as a random number generator. No obvious pattern to its output... I wonder what it was originally for? The first thing that feels obvious about this design is that I'm going to need to store the audio data for the two sound effects that Carl found - and that means, memory chips. [ ~ ]     Did Carl fire up his copy of Internet Explorer 3.0 to get at the page with those sound effects, I wonder? Each effect snippet is conveniently 13 samples long, perfect for fitting in a 200P-14 memory chip. I can't speculate as to the actual sound quality, though. Anyway, the memory chips are in, as is a MC6000 and the first half of the code - this half waits for the RNG to return a 1 (or 2) and moves it to acc if so. If it's not either, it sleeps until the next time unit. The only remaining part is actually playing the audio. [ ~ ~ ]      Ta-da! One haunted audio-playing code part, as requested! The 'play' code loops to play the audio - it reads the audio sample from the correct chip (based on the value we put in acc earlier), pushes it out to the speaker, then waits for the next time unit. The memory chips' auto-increment is really useful here - once I read a sound sample, the memory chip will immediately provide the next one when I read again. There's a few tricks I use to get the 'play' part to work right - first off, none of the effects have the sample '50' (audio silence) in them, and the memory chips each had a free slot at the end. So, I put a 50 in that slot. When the MC reads the 50, it knows it's read the entire sound effect and that it can go back to waiting (it doesn't jmp back to the label play:, so the code path falls through to the top). The only other thing of note besides the audio-playing code is the @ mov 50 p1 at the front of the MC's script, which initializes the speaker when the device is turned on. For all that this feels like a vaguely terrible thing to do to someone, I can't help wondering where this is going to end up. Could it show up on whatever the Chinese equivalent to Twitch is? That'd be interesting...!  Told you so. I wonder if David is free this evening to indulge in some "traditional Chinese cocktails"? PS: I looked up "ghost shifts". It took me a while to find a definition... apparently it refers to, at least traditionally, where a factory making something will make the thing on two shifts, then make more-or-less identical counterfeit versions (well, technically counterfeit) for outside sale during the 'ghost shift'. Does our factory have ghost shifts that work like that?!  PPS: Speaking of ghosts and supernatural monsters and so on, there is one bright spot in the stuff I've been doing lately. I’ve been getting into some of the local TV shows (thanks to the big networks helpfully providing English subtitles). There’s one - it’s called My Roommate Is A Lamia! - that’s pretty good! The special effects are pretty amazing just by themselves, and the plot is… well, it’s pretty fun. Wacky, but fun. The main guy has just figured out that his roommate is... well, you know... and I'll keep y'all posted how it goes from there.
|
|
#
?
Sep 11, 2018 21:49
|
|
|
Growing the Company - Please Read This email arrived the next day after the haunted doll thing. To be honest, Lili nailed something that has been personally bothering me for a bit - some of the stuff I've been making here is... stuff. Some of it is Joe's, uh, 'ideas'. But the ratio of potentially useful or fun projects to dubious projects has been a bit skewed for my liking. Of course, the question is, is this going to change in the future? RickVoid posted:Gah, I feel a little bad now, but it's good to know that Jie is seemingly on top of things (I assume that e-mail was supposed to go to him only). Maybe this'll be the kick in the pants Joe needs. I don't think Joe reports to Jie, actually. Jie's the chief Engineer, but that just makes him my boss and Carl's. Of course, this just means that Joe meant to send the message to someone higher up the chain... azsedcf posted:Want to save ¥1? OK, two separate responses here. First off: Bridges are actually free! Well, OK, they're not free free. Longteng does pay something for them, but the cost is really, really marginal. I think it's something like ¥.026 per bridge, or thereabouts. Second: Wait, you can run wires under chips?! I did not know that at all! I'm going to have to test this out at some point!! Computer viking posted:Something about this makes me want to write a short introduction to x86 assembly... I miss binary shift-compatible registers. Decimalized MCs are... strange. You should totally write it, though!
|
|
#
?
Sep 11, 2018 21:50
|
|
|
I love Jie diving into the conversation like "Yes, this is exactly my kind of stupid."
|
|
#
?
Sep 11, 2018 22:18
|
|
|
I can't believe Joe still has a job after that.
|
|
#
?
Sep 11, 2018 22:31
|
|
|
Quackles posted:Second: Wait, you can run wires under chips?! You can even connect them to chip ports from under them without them having to go around.
|
|
#
?
Sep 11, 2018 22:54
|
|
|
Okay, kinda worried here. Joe's ideas aren't always good, but the last couple times Lili has given you an assignment its been something related to combat or security, if she's trying to get the company to focus on something that builds a future for the company, you may have more contracts like that coming your way in the future.
|
|
#
?
Sep 12, 2018 01:52
|
|
|
Ghost shifts have almost always been a thing, where did you think all of the extremely good counterfeits come from? There's enough of them to fill entire shopping centers.
|
|
#
?
Sep 12, 2018 06:22
|
|
|
Could you hook that ghost chip up to a radio transmitter and have haunted Cool Dad vapes? Hang on, you can prototype basically anything, right? It might be kinda cool to see a ghost chip hooked to an LED for a random color cycler. Take out the vape middleman.
|
|
#
?
Sep 12, 2018 13:20
|
|
|
I don't think China is much of a traditional cocktail country. Think it's more straight rice wine at 80% alcohol content or something stupidly high. Feel free to prove me wrong though.
|
|
#
?
Sep 12, 2018 15:00
|
|
|
There an actual recording of the haunted babies, or does the simulator just track "ok, on, and now off"?
|
|
#
?
Sep 13, 2018 18:35
|
|
|
If somebody likes X86 assembler, I can recommend these videos. The first one explains in simple terms (relatively) how the Meltdown vulnerability is exploited. https://www.youtube.com/watch?v=I5mRwzVvFGE These videos are much more involved; the first explains how this guy built a tool to find undocumented operations in CPUs: https://www.youtube.com/watch?v=KrksBdWcZgQ The second one explains how the same guy used that tool (from last year) to find an exploit in an obscure X86 clone that is millions of times worse than Meltdown: https://www.youtube.com/watch?v=_eSAF_qT_FY
|
|
#
?
Sep 14, 2018 21:09
|
|
|
klafbang posted:If somebody likes X86 assembler, I can recommend these videos. I just watched both Blackhat videos. Those were very interesting, thanks for sharing.
|
|
#
?
Sep 15, 2018 11:28
|
|
|
Custom Specifications This is cool! I'm now able to make my own specifications (assignments, basically). (No screenshot of ConceptSPEC in action, alas. It's old enough that the tablet's screenshot function bugs out.) This is pretty cool, but the question is - what do I do with it? I can't think of any obvious applications... right now. Useful to have, though! Ibblebibble posted:I will say, as an Asian guy from Asia and in Asia ATM I would indeed rather die than give up cheese. Oh right! I allllllllmost forgot to mention - here's Carl's favorite sandwich.  inflatablefish posted:I can't believe Joe still has a job after that. I can confirm he has a job, but, well, I haven't seen him in the office much lately... Deathwind posted:Ghost shifts have almost always been a thing, where did you think all of the extremely good counterfeits come from? There's enough of them to fill entire shopping centers. If they were made in the factory that makes the real thing, using the same materials and techniques, what makes them counterfeit? Philosophical question. Carbon dioxide posted:You can even connect them to chip ports from under them without them having to go around. I'm going to take note of this. Maybe try it out in my next job! Ashsaber posted:Okay, kinda worried here. Joe's ideas aren't always good, but the last couple times Lili has given you an assignment its been something related to combat or security, if she's trying to get the company to focus on something that builds a future for the company, you may have more contracts like that coming your way in the future. I'll have to trust her, I guess. I mean, if things get truly untenable, I could always quit. It'd be a big step, though, as it would almost certainly mean leaving China and a comfortable livelihood. Anyone know of any sort of, like... other people who might want engineers? Dareon posted:Could you hook that ghost chip up to a radio transmitter and have haunted Cool Dad vapes? Haunted vapes... now THERE's an idea.  And yeah, here's what it looks like:  mercenarynuker posted:There an actual recording of the haunted babies, or does the simulator just track "ok, on, and now off"? The simulator checks that the correct sound samples are output at the correct time. I got to see the thing working on the archive of the livestream Joe mentioned, and the audio was... actually kind of terrible. Very fuzzy. Ibblebibble posted:I don't think China is much of a traditional cocktail country. Think it's more straight rice wine at 80% alcohol content or something stupidly high. Feel free to prove me wrong though. You're probably right. If I remember my old history classes, fancy cocktails really got going in the US in part as a way to mask the taste of dubiously-processed alcohol during Prohibition. There's no Chinese equivalent. Mind you, if a traditional Chinese cocktail does exist, David'll find it.
|
|
#
?
Sep 16, 2018 10:11
|
|
|
Aquaponics Maintenance Robot I'm feeling a little relieved. This is a serious project, it's not defense-org-y at all, and the only fishy thing about it is that it's part of a system that is full of literal fish. I'd give Lili a high-five if she was the kind of person to be into high-fives.    Looking at the design, this definitely feels like a two-MC project. There's three outputs - and two of them (the feeding and cleaning tools) do only need to be pulsed, so the design could use an output expander - but if I were to use an expander, it'd take five instructions to pulse the outputs versus two without one.* There's also the matter that there's no way to get the current position of the arm. Whatever I build will have to keep track of that itself - over multiple time units, given that the arm can only move one space at a time. *( {mov 100 x#, slp t1, mov 10 x#, slp t2, mov 0 x#} versus {gen p0 t1 0, gen p1 t2 0}. ) With that in mind, I think a preliminary design would look something like this:    The code for the first MC is pretty much written. It waits for data from the receiver, then passes the destination on to the second MC (which will control the motor). Then, once the second MC signals the arm is in place, the first MC uses gen to pulse the cleaning / feeding tools. (This relies on the trick I learned about after the virtual reality buzzer job - that the radio will hold the back end of the data packet until the first MC asks for it.) Now I just have to write the code for the second MC. [ ~ ]    Remember how I said the design would have to keep track of the position of the arm over multiple time units? It turns out, to make the motor routine work, it has to keep track of both the current position of the arm... and the destination. Which requires two registers to keep track of. As such, the second MC is now a MC6000. acc stores the current position, dat stores the target position - the MC waits for a destination, then pulses the motor and updates acc to match the new position. (In case you're wondering about the gen instructions, they set the motor to 100 or 0, respectively - the 'mov 50' resets it back to a neutral state afterwards.) So this design is a wrap. ¥8, 196 average power. Pretty efficient, in my opinion. That said - I think there at least could be a way to do this with two MC4000s. A lot of instructions on the big MC are repeated, so it feels like the number could be lowered - but how to cope with the loss of the extra register? I'll have to fiddle with it a bit. [ ~ ~ ]    Success! Suc-freaking-cess! Getting the job done with ¥6 (and 277 average power) required redesigning a lot of things. First off, there's the question of where to store the arm's destination. The first MC uses its acc to store the destination now - it repeatedly sends it to the second MC every other time unit until the second MC reports that it's at the location. (The jmp to 'redo' is the loop.) The second MC has been simplified. It just reports its current location, then updates its acc (the current arm position) and pulses the motor.  There's only one other wrinkle that's not obvious. The first MC doesn't have a way to check whether or not to fire off the gens.** But. It turns out that if you have a gen instruction with a duration less than 0... the MC won't do anything for that part of the gen pulse. It's treated as though you said "gen p1 0 0" (which does nothing) instead of "gen p1 x1 0". This way, when the MC receives a -999 from the radio, it runs a gen pulse for -999 (really 0) time units. No conditionals needed! **(In case you're wondering, the flag used for the loop ( – ) - note that the loop must not run on a -999 - can't be used for the gen pulses, because the opposite flag ( + ) is set when the loop exits. But that same flag is set during the first test if the loop never runs, so whether I set those gen instructions to + or nothing wouldn't matter, as they'll always run.)  Interesting. I wonder if Mr. Haotian is investing in sustainability technology? Aquaponics systems can be set up in ways that they don't really require too much in the way of outside inputs, so this could be useful for, for example... feeding people in developing nations? Or in places where outside stuff can't easily get? Long-term rebuilding after disaster recovery, maybe? We'll have to see. P.S: I finally figured out something I can do with the prototyping area!  I'm not ready to say just what it is yet, but let's just say that my Secret Project is underway... Quackles fucked around with this message at 01:24 on Sep 22, 2018 |
|
#
?
Sep 16, 2018 10:11
|
|
|
This stuff is super interesting, and is making me consider trying to get through Carnage Heart EXA's long-rear end tutorial (which is framed as a sort of story mode of a tutor teaching a dude how to program giant murder mechs.)
|
|
#
?
Sep 16, 2018 10:36
|
|
|
It's more complex than I would have expected for a musical greeting card.
|
|
#
?
Sep 16, 2018 10:37
|
|
|
Dude's just trying to make the world's dankest grow op. 
|
|
#
?
Sep 16, 2018 10:38
|
|
|
Hey, how're you surviving the Shenzhen hurricane season?
|
|
#
?
Sep 16, 2018 11:01
|
|
|
+mov programmers inland
|
|
#
?
Sep 17, 2018 14:31
|
|
|
So, x86 assembly. I've spent some days thinking about how to give a taste of it in a way that's approachable and looks slightly relevant to the thread. The most approachable form it has had is probably in the 16-bit, realmode DOS days; I've just spent a few hours poking around in dosbox, writing my first VGA mode programs since my qbasic days in the 90s. It was surprisingly fun, so I'll just jump straight in. I'll do this in two posts: One with background information, and one with a small demonstration program. I'll hopefully be able to do something more interesting (with VGA graphics) in a later post. First off, a short history of the modes.
DOS is a 16-bit OS, so it's intended for running real mode programs. There are ways to run a protected mode program in DOS, though - if you've seen a message about DOS/4GW, that's what it's for. I won't go into that. One of the weirder features of real mode is the memory model. All x86s modes are "byte addressable", which means that an address can point to any one byte in memory. In real mode, the addresses are 16 bits long, so you can only address 65535 unique bytes - 64 kilobyte. However, the CPU internally can handle 20 bit addresses; enough for 1 MB. In order to make use of more than 64kB, real mode has a set of segment registers that you can use in addition to an address. The idea is easy enough: You define a segment somewhere within the megabyte, and then your addresses are offsets from the start of the segment. The way intel chose to do this is a bit peculiar, but we'll cross that bridge when we get to it. (One of the big quality-of-life benefits to 32-bit protected mode is that you can address 4GB without ever touching a segment register.) As for tools, I'll be using FASM inside DOSBox. FASM is actually a protected-mode program, so it requires a helper tool like CWSDPMI. I'll be writing the actual code in a windows text editor outside dosbox, though I'm sure you could find a copy of Microsoft EDIT if you wanted the proper feeling.
|
|
#
?
Sep 17, 2018 22:10
|
|
|
First off, let's set up our environment: Unpack FASM and CWSDPMI to a folder with a convenient name - I used c:\asm , and put the fasm files directly inside, and the dpmi things in a subfolder. Start dosbox. Inside, type mount c: c:\asm to make that folder your C: drive, and c: to go there. Start cwsdpmi - for me, it's dpmi\bin\cwsdpmi -p . To compile (ok, "assemble") a text file into an executable .com file, use fasm in.asm out.com. Let's start with something traditional: code: So, what happened there? There are a number of things to unpack. The org 0x100 informs FASM that when this program is started, its first byte will be at position 0x100 (100 hex; 256) in memory. This is just how DOS does things. Intel assembler syntax is reversed compared to most others: The destination is always the first argument, so mov ah, 9 moves 9 to the AH register. Intel real mode has a handful of registers. There are weird limitations on what each can be used for, but as a first approximations, we can use AX, BX, CX and DX for whatever we want. Each of those are 16 bit long - two bytes. We can also directly use the upper or lower byte of each separately: AX can be treated as the two separate 1-byte registers AH ("AX High") and AL ("AX Low"). Ditto for BX, CX and DX. X86 has an interrupt table: A list of 256 memory addresses. An interrupt is effectively a way to tell the CPU "drop what you're doing, and jump to the appropriate address"; this can be triggered from hardware (e.g. "the disk read you asked for is done" or "a soundcard buffer is empty") or from software. All the functionality DOS provides to a program is accessed by putting the right values in one or more registers, and triggering the proper interrupt. Typically, this means putting a function code in AH and triggering interrupt 0x21. I found this overview of DOS interrupts quite useful. The above program uses two DOS interrupts: 9 ("Write string to STDOUT") and 4C ("Exit program"). Looking at 9, it's defined like this: quote:Entry: DS:DX -> '$'-terminated string DS:DX means "An address constructed from DS and DX" - so we need an address in DX. That's easy enough: Like any decent assembler, FASM lets us give any location in the program a label, and will insert the appropriate address for us. DOS uses $ to mark the end of text strings. Why is lost in the mists of time; it's something it inherited from CP/M (and Gary Kildall took his reasoning to his grave in the 90s). It's easy enough to work with, at least - as long as you don't want to print an actual dollar sign. We define text with db - "Data, byte". It can be followed by a single 0-255 number, a comma-separated list of numbers, or ASCII text. DOS call 4C is easier: It will exit the program, returning whatever is in register AH as the exit status of the program. Computer viking fucked around with this message at 22:13 on Sep 17, 2018 |
|
#
?
Sep 17, 2018 22:11
|
|
|
The funny thing is, I read posts like that, I think they're neat, but then I go "why would I ever bother with that '80s poo poo now that we have all these powerful high-level languages available". On the other hand, I really enjoy those videos about undocumented instructions, Quackles' job blog, and this video game 'Exapunks' where you play a hacker writing semi-assembly.
|
|
#
?
Sep 18, 2018 06:47
|
|
|
Modern programers are spoiled by fast processors and spare memory. It's suprising how inefficient many of the compilers for higher level languages can be. Working close to the iron is one of the only ways to truly optimize execution speed and memory usage.
Deathwind fucked around with this message at 14:23 on Sep 18, 2018 |
|
#
?
Sep 18, 2018 14:20
|
|
|
Deathwind posted:Modern programers are spoiled by fast processors and spare memory. It's suprising how inefficient many of the compilers for higher level languages can be. Working close to the iron is one of the only ways to truly optimize execution speed and memory usage. You are right, however what most programmers that need extremely high performance tend to do is write in C++ or Rust or whatever and then use those languages' low level constructs specifically for the bits that need optimizing. Writing assembly as-is seems to be incredibly rare.
|
|
#
?
Sep 18, 2018 17:36
|
|
|
Carbon dioxide posted:You are right, however what most programmers that need extremely high performance tend to do is write in C++ or Rust or whatever and then use those languages' low level constructs specifically for the bits that need optimizing. I have used x86 asm blocks in modern C++, but for ridiculously short and specific things like adding rep; nop in a spinlock. However, most high-performance C++ code on x86 uses vector intrinsics to make use of SSE, AVX and all those. Intrinsics aren't themselves assembly, but they are trivially and directly converted to x64 mnemonics of the same name so it's still pretty drat low level: you just don't have to reason about register use. There's still a few hundred thousand programmers who code in an assembly every day, though. They just work in embedded and write the code driving things like the signal processors in your local cell phone tower, the microcontroller for your toaster, and other Shenzhen I/O-like things. There are a lot of platforms out there were the best "high level" language you might get is a barely-supported C compiler that you're strongly discouraged from using. Going by the folks I know writing specifically the cell phone tower code optimization is definitely a concern: the power and latency restrictions they're working under are getting vaguely ridiculous.
|
|
#
?
Sep 18, 2018 18:31
|
|
|
Conversely, there's a bunch of important optimizations for fancy chips that compilers are much better at doing than people. Stuff like exactly how many times to unroll a loop before the code doesn't fit in an instruction cache anymore or making good guesses about what pieces of hardware inside a superscaler CPU are in use and reorganizing instruction so the hardware can overlap them. Humans can do all those things too, but the benefit/time tradeoff is heavily weighted towards letting a machine do it.
|
|
#
?
Sep 19, 2018 06:12
|
|
|
Foxfire_ posted:Conversely, there's a bunch of important optimizations for fancy chips that compilers are much better at doing than people. Ah yes, I also heard some stuff about making sure everything you need stays in the tiny, but incredibly fast L1 cache of your CPU.
|
|
#
?
Sep 19, 2018 06:44
|
|
|
Yep. On an i7-8700K hanging out at 3.7GHz: - RAM transfers to L3 at 5.3GB/s. It's many GBs big - L3 transfers to L2 at 118GB/s. It's 12MB - L2 transfers to L1D at 237GB/s. It's 256KB - L1D also transfers to CPU registers at 237GB/s. It's 32KB (it's low-latency compared to L2) As it clocks itself up, all the CPU ones go up by 25% too, the memory stays at its lazy snail pace. If things regularly have to wait for RAM, they're super slow
|
|
#
?
Sep 19, 2018 08:01
|
|
|
Another of the design ideas of the x86 cache hierarchy is to make repeated "local" memory access cheap. The most obvious reason is the stack*, but constructions like "base+counter" pop up everywhere. Looking at the intel skylake/coffee lake family, the L1 and L2 caches store 64 byte blocks of data, and they are write-back: if you write to a cached area, your changes only go back to system RAM when the cache block is evicted. Those 64-byte blocks are aligned: their start addresses are multiples of 64. This means that to make efficient use of cache, you want to sure your data starts at an aligned address - and it may be worth using more instructions if it lets you stay inside a block. On a higher level, this is also an argument for sometimes using what may look like a slightly slower algorithm - if it has better cache locality, it may end up being faster. (This all kind of reminds me of some of the early machines, like the PDP-8, where you had very few registers but reading and writing to the first 256 bytes of RAM was cheap and easy.) * x86 has a dedicated register pointing to a place in memory where you push things you want to set aside for a bit, and a pair of instructions that "push" a register there or "pop" it back, while moving the pointer back or forth the right amount of bytes. This is especially useful when you call a function that may mess with what's in all your registers: push everything first, and pop it back afterwards. If that function calls another function, it does the same - the stack can grow large with deeply nested calls. If you run out of space, you have a stack overflow.
|
|
#
?
Sep 19, 2018 10:25
|
|
|
Foxfire_ posted:Conversely, there's a bunch of important optimizations for fancy chips that compilers are much better at doing than people. The big reason for doing hand optimization is to make sure the branch prediction makes the right guesses (or doesn't have to make a guess by transforming conditional to algebraic computations or loop-ups). Secondary, once you've spent a week or two hand-optimizing a tight loop, you get ideas for adjustments to the algorithm. I once worked on invisible watermarking of live video, and after standard vectorization and linearization, we made an adjustment to a precomputed grayscale gradient from 64 to 16 or 32 levels, allowing us to use in-CPU look-up-tables.
|
|
#
?
Sep 19, 2018 12:07
|
|
|
Incredible Opportunity: Land Rich in Rare Earths In the book Martin Chuzzlewit, by Charles Dickens, there's a section set in the then-burgeoning US of A. The title character travels to the US to seek his fortune, being told of a wonderful opportunity of prime settling-down land, where there is a town called 'Eden'; the land turns out to be a malarial swamp, and the offer a fraud. TLDR: This swindle is about as old as the probably-not-rare-at-all dirt in question. Carbon dioxide posted:Hey, how're you surviving the Shenzhen hurricane season? No big typhoons aimed (directly) at us for 2026, so far - thank goodness. Mind you, I spend something like 95% of my time indoors and I've been assured that a lot of these buildings have been extra-reinforced to withstand high winds (especially after Typhoon Mangkut blew out windows, etc. in 2018) - if there was a typhoon on the way, I'd probably get time off work. Apparently standard procedure is just to stay indoors and wait it out. Dareon posted:It's more complex than I would have expected for a musical greeting card. That's just the bass line.  Deathwind posted:Modern programers are spoiled by fast processors and spare memory. It's suprising how inefficient many of the compilers for higher level languages can be. Working close to the iron is one of the only ways to truly optimize execution speed and memory usage. Foxfire_ posted:Conversely, there's a bunch of important optimizations for fancy chips that compilers are much better at doing than people. I guess what you're all saying is that for optimal results, you need human optimizations AND compiler optimizations... but couldn't compilers learn to do the human optimizations? Some energetic people should look at it. Mind you, I know 'compiler maintainer' isn't a job for everybody... or many people. I once took a compilers class in college, but then I took an arrow to the knee.
|
|
#
?
Sep 22, 2018 11:33
|
|
|
Remote Kill Switch One of the things that it's easy to forget about Jie is that he is still an engineer and does do engineering work, even if he also manages the rest of us. What he's suggesting seems like quite a sensible precaution, though I'll have to see the details of the spec to understand what sort of equipment is expected to be connected to this thing.    There it is, in black and white: 'industrial equipment'. I'm guessing the sort of high-powered robots that assemble cars or that sort of thing? Looking at this, I can tell right away I'll need two MCs for this. The reasons follow from the design. First off - putting an output expander in front of the three outputs seems perfect here, given that the outputs are always on or off (no in-between). One of the MCs has to use its acc to keep track of the state of the outputs (which we can change incrementally by using dst instructions to set individual digits of acc to 1 or 0 before that value is pushed to the expander). The thing is, we also need to use an acc as a counter to keep track of how long it's been since we received a pulse from the transmitter (because only accs can be added to / subtracted from). This means, another MC. With that in mind, here's an initial design sketch:    This seems pretty straightforward, though chip sizes are subject to change. Time to get to work! [ ~ ]    Here's my first design. ¥11, and 507 power usage on average. I had to bump the first chip up to a MC6000 so it can use dat to store the radio signal. If it gets nothing, it adds 1 to acc (counting how long it's been since the last pulse); if it's been too long, it sends -1 (override) to the second MC. Otherwise, the first MC just passes the command on (if it's a command) or sleeps (if it's a keep-alive pulse). The second MC... I'm not as proud of. It just waits for notification from the first MC, and either sets acc to 0 (in the case of an override), or modifies the appropriate digit of acc with the dst instructions (normally). Then it pushes the result out to the output expander. The thing is, I had to use both registers, which is why it's a MC6000 - but all that wasted space is gnawing at me. I could shrink it down to a MC4000, except to do that would require not using dat, and I have to use that now to cache the first value (which power supply to change) from the first MC. (I did try to read from the first MC twice in one tick. It turns out you can't do that - at least not on the same pin.)  Maybe if I could make it read using different pins (so something like "dst x0 x1" and read the two values in order)? I might be able to make it work if I used a MC4000X for the second chip. I'll think about it some more. [ ~ ~ ]    It looks like using a MC4000X was the right call. (¥9 and 489 average power, so this is an unequivocal improvement.) I realized that I didn't even need to have two different pins of the first MC hooked to the second. When a 'power change' command arrives, the first MC has to read the first value— but it can leave the second in the radio and have the second MC pick it up directly. This lets the dst x1 x0 work, pulling in both values in the same tick and sending the updated acc out to the expander immediately afterwards. This seems like a good design, and Jie will be pleased. I wonder if it'll end up on our own factory floor? No more smashed-part incidents like the one that happened back near when I started.  Ho-ly crabapples. I'm completely in line with Carl on this - imagining Jie talking like Joe is... well, I don't have to imagine it, it's right there! But Joe is more idiomatic than a lot of Californians I know! ...does this mean that Joe is kind of like... Reverse David, in a way? There's a scary thought. I think maybe because it could be true. P.S: I added a gif of the aquaponics arm at work to that post - I forgot to include it when I originally posted it. Check it out! (GIF is near the bottom) P.P.S: Still watching My Roommate Is A Lamia. The most recent episodes have introduced a (more or less normal) best friend to the protagonist - she's a definite foil to everyone's favorite lamia, though. The showrunners are definitely trying to get a romance started between the guy and his lamia roommate, but said best friend's plans to start a band have been schedule-blocking it big time. If there's any other Lamia fans reading the blog: my guess is that he joins the band. That beat-up bass guitar in his closet didn't get put there just as background...
|
|
#
?
Sep 22, 2018 11:34
|
|
|
|
| # ? Apr 29, 2024 10:49 |
|
|
Getting some 诚尚Micro vibes from this:Cygni posted:I cant remember if it was this thread or the Intel thread that was talking about VIA's x86 license a while back, but the 2nd gen product from the Chinese govt company using the license just came out. Claims to have 8 cores at 3ghz, using the 16nm TSMC process.
|
|
#
?
Sep 24, 2018 20:56
|
|
