search

SDL-Hercules-390 / hyperion

The SDL Hercules 4.x Hyperion version of the System/370, ESA/390, and z/Architecture Emulator
Other
240 stars 90 forks source link

Add opcode stub for 0xe7xx range (vectors) #436

Closed lucyllewy closed 2 years ago

lucyllewy commented 2 years ago

Add assembly opcode stubs in the 0xe7xx range with commentary indicating all the vector instructions.

Signed-off-by: Dani Llewellyn diddledani@ubuntu.com

lucyllewy commented 2 years ago

I figured that having them in place ready for implementation made sense, but I can see your point of view.. I'm happy to leave this off, though I'm hoping to have a look at implementing a couple if I can learn C well enough (I'm very much a C novice, and a complete emulation and Mainframe newbie!)   ;-p

Fish-Git commented 2 years ago

I figured that having them in place ready for implementation made sense, but I can see your point of view..

And in reciprocation I can certainly see your point of view too!

But in my experience, adding [currently unneeded] code "ahead of time" in anticipation of an eventual upcoming change (commit) to start making use of the previous "preparatory" (but currently dead/unused) coding change only ends up introducing unneeded complexity to the code base thereby hindering development efforts in the mean time (i.e. while waiting for the "eventual" "future" "upcoming" code change, which all too often ends up never arriving!).

Saddling developers with having to maintain dead code (code that is never actually used) is in my experience a bad thing, as it only serves to complicate development efforts thereby increasing the possibility/opportunity for bugs to be introduced.

Once the new code is ready, then you can commit it to the repository in incremental pieces (i.e. in a series of multiple commits, with one of those commits being the "preparatory" (groundwork) commit), but until the ENTIRE change is ready, to commit only part of it now, when it is currently not needed, in anticipation of an eventual future commit of (currently unwritten but well intended) code that will use it, only "dirties" an otherwise clean code base for, IMHO, no good reason.

Which is not good.   :(

I'm happy to leave this off, though I'm hoping to have a look at implementing a couple if I can learn C well enough (I'm very much a C novice, and a complete emulation and Mainframe newbie!)   ;-p

I look forward to your efforts to try and code some of these instructions!

I suspect you're going to be in for a real challenge, but then what's life without challenges, eh?   ;-)