mirror of
https://github.com/SDL-Hercules-390/hyperion.git
synced 2026-07-26 02:29:51 +02:00
gottfriedleibniz
d79382bbfe
* chore: run codespell on source/header files Fixes most reported typos discovered by codespell (while trying to be unopinionated about American vs. British English). * chore: run codespell on build/readme files
196 lines
9.2 KiB
Plaintext
196 lines
9.2 KiB
Plaintext
--------------------------------------------------------------------------------
|
|
|
|
|
|
---------------------
|
|
HERCULES TODO IDEAS
|
|
---------------------
|
|
|
|
|
|
(in absolutely *NO* particular order)
|
|
|
|
|
|
|
|
NOTE: ideally a separate GitHub "Issue" should be created for each of these!
|
|
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
*** STOP WASTING VALUABLE HOST INSTRUCTION CACHE! ***
|
|
*** STOP WASTING VALUABLE HOST INSTRUCTION CACHE! ***
|
|
*** STOP WASTING VALUABLE HOST INSTRUCTION CACHE! ***
|
|
|
|
Redesign instruction decoding and dispatch to eliminate the need for
|
|
each instruction function to decode it's own damn instruction!
|
|
|
|
Instead, decode each instruction by INTRUCTION FORMAT, and place the
|
|
results into a UNION somewhere (such as somewhere in REGS) so that
|
|
when the instruction is DISPATCHED, it can just immediately execute,
|
|
without having to decoding it own instruction!
|
|
|
|
------------------------------------------------
|
|
DECODING AN INSTRUCTION IS THE RESPONSIBILITY
|
|
OF THE INSTRUCTION DECODER, NOT THE INSTRUCTION
|
|
DISPATCHER OR THE INSTRUCTION ITSELF!
|
|
------------------------------------------------
|
|
|
|
The idea here is, there are literally HUNDREDS of instructions in
|
|
the architecture which all use the same instruction format as other
|
|
instructions:
|
|
|
|
There are 220 instructions using the "RRE" instruction format
|
|
There are 114 instructions using the "RXY-a" instruction format
|
|
There are 59 instructions using the "RRF-e" instruction format
|
|
There are 57 instructions using the "RR" instruction format
|
|
|
|
...etc...
|
|
|
|
Which means there are literally *MANY HUNDREDS* of places throughout
|
|
Hercules where the exact same REDUNDANT code exists, BUT ALL AT A
|
|
DIFFERENT PHYSICAL HOST INSTRUCTION/STORAGE ADDRESS! (meaning each
|
|
one consumes its own separate set of host instruction cache lines!)
|
|
|
|
Hercules is wasting literally *HUNDREDS* OF TIMES more of the host
|
|
CPU's valuable INSTRUCTION CACHE than necessary! HOST CPU Instruction
|
|
Cache that could better be used to cache yet other parts of Hercules,
|
|
thus helping to speed up not only Hercules, but also the ENTIRE HOST
|
|
SYSTEM ITSELF TOO!
|
|
|
|
------------------------------------------------
|
|
DECODING AN INSTRUCTION IS THE RESPONSIBILITY
|
|
OF THE INSTRUCTION DECODER, NOT THE INSTRUCTION
|
|
DISPATCHER OR THE INSTRUCTION ITSELF!
|
|
------------------------------------------------
|
|
|
|
*** STOP WASTING VALUABLE HOST INSTRUCTION CACHE! ***
|
|
*** STOP WASTING VALUABLE HOST INSTRUCTION CACHE! ***
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
*BUG*: FIX PORTABILITY ISSUES that have crept in over time.
|
|
|
|
Remove all "#if defined(__APPLE__) || defined(__FreeBSD__)" statements.
|
|
|
|
You should NOT test for specific platforms. Instead, create a configure.ac
|
|
test for specific functionality or for a specific feature that your code
|
|
requires, and then #define HAVE_FEATURE_ABCXYZ if a platform supports it.
|
|
Then simply use #if defined(HAVE_FEATURE_ABCXYZ) in your Hercules code.
|
|
|
|
That way if a given platform begins supporting a feature that it previously
|
|
did not support, YOU DON'T HAVE TO CHANGE ANY HERCULES CODE AT ALL. This is
|
|
called "Writing portable code".
|
|
|
|
ONLY if you cannot design a test for the needed FEATURE within configure.ac
|
|
may you then add a test for a given platform, and then ONLY in "hostopts.h".
|
|
|
|
Our "hostopts.h" header is the ONLY SOURCE MODULE where tests for specific
|
|
platforms should be done. Test for the platform and #define your FEATURE
|
|
accordingly. Elsewhere in Hercules you then test for that #define FEATURE.
|
|
|
|
Windows is the only allowed exception to the rule. You may test for _MSVC_
|
|
or _WIN32, etc, but for non-Windows platforms #define HAVE_FEATURE_ABCXYZ
|
|
and then test for that instead.
|
|
|
|
Refer to "hostopts.h" for an example of the technique I'm referring to.
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
Examine all instances of "#if 0" and "if 1" and determine which should
|
|
stay and which should go. For those that should be kept, add comments
|
|
documenting the rationale for keeping it.
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
Determine optimal run_cpu/run_sie loop value taking into consideration
|
|
typical/average real host milliseconds/microseconds to complete a real
|
|
dasd I/O and typical/average number of typical workload guest instructions
|
|
that can be executed within that amount of time. The idea here is to NOT
|
|
continue looping executing guest instructions if there's a guest interrupt
|
|
waiting to be taken. This ensures timely guest notification that their
|
|
I/O has completed instead of having them "wait" much longer for the I/O
|
|
interrupt to occur because we're busy burning CPU executing instructions
|
|
instead of taking/processing an interrupt. (I.e. we don't want to "delay"
|
|
notifying them of their pending interrupts any longer than necessary.
|
|
IDEALLY we should call INTERRUPT_PENDING() macro after every instruction
|
|
but that slows Hercules down to crawl, which is why we execute multiple
|
|
instructions in a loop in the first place before calling INTERRUPT_PENDING()
|
|
macro. We don't want to call INTERRUPT_PENDING() macro TOO often, but we
|
|
should MAYBE be calling it more frequently than we are. The trick is to
|
|
determine HOW often it should be called for best performance ON A GIVEN
|
|
HOST SYSTEM. It should be a dynamically calculated value that is calculated
|
|
during startup to prevent our current defined fixed value from unfairly
|
|
penalizing those users with slower/faster Hercules host systems.
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
Suspend/Resume:
|
|
|
|
Add filename option to suspend/Resume command.
|
|
Resume option to issue start command if resume is successful.
|
|
Suspend/Resume command needs prompts/error messages: Ask Y/N confirmation
|
|
during suspend if overwriting existing suspend file, error message when
|
|
resume command given and machine is not in the reset state.
|
|
Add missing Suspend/Resume support to tape devices.
|
|
Add missing Suspend/Resume support to CTC devices.
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
Add 'const' to as many functions' arguments as possible.
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
Per Mark Gaubatz, we need a new dasd util to fix CE/SA alt cyl issue
|
|
for existing dasds created using the old dasdinit.
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
Card reader: @stack support, like Ivan's tape autoloader, to provide
|
|
ability to specify different options (ascii/ebcdic) for each i/p file.
|
|
Then you could stack a VM USERID card in ebcdic followed by a normal
|
|
ascii text file (which would be auto-translated to ebcdic of course),
|
|
or vice-versa: an ascii USERID card followed by ebcdic binary data.
|
|
Would make getting VMARC files into VM much easier without having to
|
|
mess with a ebcdic USERID card.
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
Design a way for users to define command synonyms. (dynmod?)
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
Windows block device support (i.e. ability to define an entire physical host
|
|
drive (Windows drive letter / partition) as a Hercules dasd)
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
Full 2540 reader/punch support! mode=1 (normal), mode=2 (binary/"card image")
|
|
hopper selection, etc.
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
ISSUE: there's the possibility for "socketpair" function to connect to some
|
|
other socket other than the pair's listening socket due to some other socket
|
|
on the host already listening for connections on INADDR_LOOPBACK. Fix is to
|
|
change the "socketpair" function to use a starting port# and SO_REUSEADDR
|
|
in a 'setsockopt' call and detect (HSO_errno == HSO_EADDRINUSE) return code
|
|
in its 'bind' call and auto-retry again using next port# (in a loop). Refer
|
|
to the "console_connection_handler" function for reference.
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
Device or facility per Gerhard Postpischil's 9/20/2007 suggestion
|
|
that allows one to generate random "problems" (i/o errors, machine
|
|
checks, etc) for better software error recovery testing.
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
Add new "+rdbwd" 3590-device-only option to set flag in
|
|
TapeCommands3590 table to allow/accept Read Backward CCW.
|
|
(Requested by "herc_fun" = Charlie <os_390@hotmail.com>)
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
Generic native host SCSI support (mostly for tape,
|
|
but having it opens other interesting possibilities)
|
|
|
|
--------------------------------------------------------------------------------
|