"Fish" (David B. Trout)
"Fish" (David B. Trout)
### _**FYI:**_ I've changed the title of this GitHub Issue to better reflect the actual core underlying problem. The original "forward-porting of channel-based I/O" issue as described in Harold's [README.IOARCH...
> Is it worth creating a new table for each architecture? That's the direction I'm leaning in right now, yes. In fact, I'm thinking of maybe making all of the...
> Nope. Both "S" format. But yes, you do bring up a good point: there's nothing preventing a reused (repurposed?) opcode from using a different instruction format from what it...
> On that point, I wrote a program quite a while back that generates various PDF reports based on the processing of a simple copy & paste from one of...
> No need to include CONCS and DISCS in 390. Agreed. We already settled that issue earlier. But I figured I could deal with that issue later. Right now I'm...
Okay, I think I have a workable solution. It builds cleanly and runs correctly. Whether or not it's a simple and straightforward/elegant solution is an entirely different matter of course....
> `make check` fails with: > Test "STFL and STFLE": 9 OK compares. 3 failures. Yes, I know. I forgot to update the `stfl.tst` test to account for the new...
> I forgot to update the `stfl.tst` test to account for the new facility bit that is now enabled by default Since we're on the subject... I question our actual...
Hmmm... Okay, that makes sense I guess. Remove just the testing of the bit values but leave everything else as-is (i.e. keep the Specification Exception test in the program and...
> I agree with that. Aye, as do I too. So it's settled then. I'll go ahead and do that. I'll probably commit ALL of my changes (stfl.tst included) some...