Part 7: Mitsuzen HDI-10

Part 7 - Mitsuzen HDI-10


=== Trash World Inbox ===

Interesting. I attempted this but couldn't make it work. You could start with an EXA that stores the first two values in X and T, then REPLs, write those two into a file, and meanwhile another EXA grabs the "Cheese" from file 280. But no matter what I tried it would take more than 13 cycles.

Yeah, those are good points. I don't remember from the top of my head which of these we're going to see but we'll find out.

As for the system catching illegal commands - well, EXAs as sort of virtual robots making their way through a computer system is a bit of a stretch as it is, so I wouldn't worry about it that much.


=== Mitsuzen HDI-10 - Left Arm ===



Looks like someone else discovered the Dumpster Donuts recipe too.



This time two assignments pop up. Since my arm is hurting a lot I'll start with this one.

I'm not entirely sure if you need to do both to continue. On my initial playthrough I just did them in order and I'll do the same now.

So about that left arm of yours.
The medicine stops your condition from spreading, but it can't fix things like that.
You'll need to take care of that yourself.



One vote for Uhh..., four for This is going to be weird. and five for You mean, hack my own body?

You mean, hack my own body?

Yes, exactly.
If you can hack anything else, why not your own body?

...I feel like hacking computer programs is not quite the same as messing with living tissue.


New OST: EXA Power

Assignment:
- Read a value from the nerve connected to your central nervous system (CNS) and relay it to the nerve connected to your arm (ARM), clamping the value so that it never goes below -120 or above 50. Repeat ad infinitum.
- Since this task takes place inside a network you control - that is, your own body - it is not necessary to leave no trace. Your EXAs should be written to operate indefinitely.
- Note that #NERV is a hardware register, not a file. You can use it directly in your code like any other register.
- For more information about the phage, see "Debugging the Phage" in the first issue of the zine.

So, I literally need to hack my own arm right now. The Zine has a couple pages on it.





Cool, I'm going to do a completely untested procedure on my own arm. Well, uh, let's go I guess.



When the assignment says the EXAs need to operate indefinitely, in practice this means every test-round checks if they get the first 30 values right and then assumes your program works as intended. As you can see, it expects the input values as output, except when they need to be 'clamped'.



This is my first attempt. XB is simple - it just goes to the ARM nerve, waits for messages on the M register, copies those to the #NERV register and jumps back to the COPY from M in an infinite loop.

XA does most of the real work: it copies the value from the CNS #NERV register into X, uses that to check if clamping either way is necessary, sends the correct value into M, and repeats that in an infinite loop.



It isn't the most efficient solution but it works.



As an initial improvement I moved one of the clamp checks to XB. Since now each EXA only has to do one check per loop, they can do some more cycles in parallel and the number of cycles drops to 184 (but the total size grew by one).



I quickly combined the two EXAs into one initial one that gets split by a REPL instruction. It's otherwise identical from the last one, but it reduces the activity to 5.

This was just to get a low activity score.



Back to the two EXA design, a small size improvement is possible if you reuse the COPY into M or #NERV for both branches. You'll have to make sure that the execution falls through the clamp MARK instruction to the COPY to make this work.



One trick we've seen before to reduce the cycles is by unrolling the loops, like so:



This runs at 163 cycles, a nice improvement, and it's as big as we can go with size 48.

If you're wondering why I'm not using the @REP instruction, it's because we only saw that in solutions from the thread. Not everyone might read the INBOX section so I won't use them in 'story' updates until we're introduced in-game. Feel free to use them in optimizations though.

I'm not storing the clamped values into X anymore because that takes more cycles, which is what I'm optimizing for here.

It's important to spread the loop unrolling equally between the EXAs because otherwise they'll just be waiting for each other and there won't be any gain.

Since all clamp jumps use the same clamp label, doing a clamp always resets the loop but that doesn't matter since we're not keeping track of any additional data in the loop. But... that gives me an idea. What if we do put the clamp code inside the loop so we can use fall-through instead of jumps sometimes?



I went through several different designs and got it down to 155 cycles. For both EXAs the loop works the same. It first loads a value into X and checks if it needs to clamp it. If so, it does and jumps back to the start of the loop. If not, it jumps to DONTCLAMP and sends the original value onward. In that case, it continues to the next COPY to X and test.

Every time it does not have to clamp it jumps back to that initial DONTCLAMP mark and gets another free go in the loop. If it does have to clamp it passes the FJMP, uses the clamped COPY, and goes down another layer. The FJMP seems to take one cycle whether it needs to jump or not, but since we don't need an extra JUMP statement to handle the case where FJMP doesn't trigger, it gives us basically free repeats, unless we get an unclamped value followed by 3 clamped values within the same EXA.

In fact, this doesn't ever happen. It turns out I can reduce the code significantly and still get a 155 cycle solution:



Cycles = 155, Size = 32.

So, it turns out unrolling the loop doesn't speed up the second EXA at all. Huh. It does matter for the first EXA though, but not for the reason I thought. There's no situation where you got two > 50 inputs in a row. Instead, if I remove one of the additional COPY - TEST - FJMP - COPY blocks, the number of extra cycles within a single test is equal to the number of times a < -120 input directly follows a > 50 output. Apparently without the unroll, the EXAs have to wait an additional cycle for the next M transmission in this specific case.

I did some more testing and learned some more things. Nothing to get me a lower cycle count directly, but maybe it'll help the thread find the next optimization.
- Removing BOTH of those repeated blocks in XA increases the cycle count to 184, consistently for all tests. Apparently then there's always a wait happening, and it's the same as in my earlier solution.
- Switching all FJMPs for TJMPs in XA and swapping COPY 50 M with COPY X M also increases the cycle count to 184, showing that this optimization truly depends on the free loop repeats in case of a DONTCLAMP.
- Swapping the 50 and -120 checks between the two EXAs has no effect on the cycle count whatsoever.

Anyway, that's how far I got, I'll leave it to the thread to find further optimizations. Score to beat: Any of 155 cycles; 22 size; 5 activity.

By the way, there's the first part of some sort of story in the Zine. Thought I'd share it with you all.

Click the images for higher resolution.






I'm done with this assignment.

This hotfix should keep you useful, at least for a little while longer.
I'm glad I don't have a body.



And the intro for the next assignment.

You like snacks, don't you?
You don't have to answer that.
I know you like snacks.
That's why we're going to hack a snack factory.



Two questions to vote on.