RTX2001A simulator #157
RTX2001A simulator #157
Conversation
|
Some questions about this. Why are the files in a seperate src directory? Why a separete makefile? Why is there an hp3k_defs.h file in the RTX2001 simulator? |
|
Hello Richard!
Files are in src/ as there is a corresponding test/ directory that isn't part of the PR. It turns out any Rust advantage would've been strictly in the language UX. Reliant as I am on TDD, I found it impossible to make any progress w/o employing that technique for this project. I wound up adopting the
Believe it or not, I didn't discover the listserv until I was ready to create this PR. If I'd asked, I'm sure there wouldn't be a separate file.
It's a core set of definitions, as such lifted directly from that project. I didn't want to lose the provenance, and I'm not sure how to |
|
@jchimene: There are preliminary hooks in the CMake infrastructure to support Unity-based tests, which would be a future merge request. So, don't throw them away, yet. (Part of my background is in space systems, where TDD is critically important.) |
Discard cpu_boot(); Incorporate hp3000_defs.h from the HP3000 simulator by J. David Bryan;
|
HEAD now reflects the requests: It's still alpha level |
|
If the project is interested in this PR, please let me know. There's still a fair amount of debugging to get this thing operational. |
|
There is still a symlink to sim_defs.h which will not work on Windows. Also why is there one header file in the src directory? |
|
It should build cleanly on at least Linux, not only macOS. I've explained in private email the issue. |
|
If the project is interested in this PR, please let me know. There's still a fair amount of debugging to get this thing operational.
I'm not seeing src/ in my version. How are you seeing that on https://github.com/jchimene/openSimh/tree/rtx2001a/RTX2001A? The sim_defs.h file should be gone from the repo. |
I'm not sure what the issue is on Linux. The makefile is pretty vanilla right now. |
Attempt console I/O; dev vs. prod rom location; always write bad_insn log;
|
Beyond and related to the "issue on Linux", you can try to build your simulator on your macOS platform, but using a different compiler (we look for as many different compilers to examine the code for compatibility issues)., If you build with: You'll see the category of issues Linux and other platforms will have. I pointed out the details to you in a private message, and you've chosen to ignore that input. I'll state this again: You SHOULDN'T declare global variables in include files, especially in include files which are included in many places. If you follow this advice the build will work better in more places. |
|
@markpizz |
Expecting continued feedback on this PR after useful information has already been provided without being adopted is asking for a lot. Most folks here would presume that if you are presenting a Pull Request (PR), then you think it is close to be ready to be merged. Feedback about the barriers to merging, and the solutions to those barriers is what you'll be getting. I'm glad you've brought up the kbhit() subject on the simh list. That could be discussed here as well since you've exposed the code that uses it. Your simulator code should avoid using OS provided API's and OS provided include files. Include sim_defs.h and other sim_xxx.h files and use the APIs they provide. If you think you need something else, feel free to ask here or on the simh list. |
|
I can build this (tried it on a Mac, including building as universal just for fun) and it starts ok. Not sure what I can do after that point. This is a FORTH machine, right? It's a bit puzzling to see an emulated computer that only has a CPU, no I/O devices. |
|
@pkoning2 The purpose of this PR was to start a discussion of whether or not this simulator is interesting for simh. After building which is not on github as it's still in development after the above, issue the "go" command. You'll get the Harris copyright statement and then the bitbucket. |
Yes
It's purpose is to see if the simh design will provide the infrastructure to simulate a Forth machine, specifically the Novix processor with its single cycle instructions and zero-cycle return instructions. Since technical Novix documentation doesn't seem to be openly available, I selected the RTX2000 family, specifically the RTX2001A, which adds Harris' Quadbus design and ASIC library implementation. That it's an embedded controller does pose some challenges for this project. As you've noticed, there isn't much in the way of external devices. The only answer I can give now is that primitive DOS operations will be via the simh filesystem; the console, as you've seen, will be via the simh console. Should requirements for ASIC bus connections arrive, those would be accomplished via the simh UNIT subsystem. |
|
Thanks. My reaction is that yes, this seems like a fine thing to add to SIMH. It would be good to include a document for the "doc" directory that describes what this is, how to operate it, and (if relevant) where to find bits that can run on it. |
|
Hm, I tried that INI file and "go" and got a bunch of debug messages followed by an invalid opcode error. No copyright message. |
The github version needs a refresh. I've been avoiding a push until the Forth inner interpreter is on the air. |
Great! Thanks for taking this on. I appreciate the company. |
|
I've been an (occasional) FORTH user since the 1980s (I created the FORTH runtime system (somewhat extended FIG-FORTH) that's included with recent RSTS/E releases, and wrote a 4000 line tool with that. I've also looked a bit at various FORTH FPGA designs, so a FORTH processor emulation feels natural. |
It's an ineresting language. I admit I don't have much use for it day to day. I haven't seen RSTS/E since 1983. Forth and RSTS/E with its runtime system support certainly makes sense.
Good. It represents a design that's not found in other of the simulators. My pupose with simh is to illustrate the multi-issue quadbus. Here's an interesting image:
The single-cycle return and multi-issue data fetch can be logged. I've gotten to the "yep, there it is" goal via the simh debug macros. At some point, I'll devise some external bus signal visualizer. All of which assumes I can get the thing on the air. It also assumes a usable APPFORTH image. I have a growing suspicion that APPFORTH is the bootstrap that gets to usable dictionary. |
…own way." Implement console input; Repair byte addressing; Implement examine for Parameter & Return stacks; Fix size of Index bitfield in ReturnStack; Repair boot routine in simh.ini
@pkoning2 : It should build now. To start: issue the GO command, then hit Please flag non-compliance. To do that, please comment out line 7 of simh.ini to enable logging and post the last few steps to the crash.
|
Poll keyboard; Implement host_write for BYE; Implement sim_load(); Change to rtx2001a.ini from simh.ini
|
This version now handles the keyboard correctly, and can exit at the BYE command To start: then type GO, press to get an OK prompt, type BYE Not much else works right now. There is a start of documentation for this simulator. What other work is needed before approving this PR? |
The super secret formula have all been expressed again here. There are no secrets about this. Some folks prefer to work out the problem details at home rather than in the middle of the street.
The timeline you respond with is completely yours, but ultimately all the issues that have been raised need to be addressed. You are the one who specifically asked (#157 (comment)):
Then you say:
You get to pick and choose the order you address the issues, but you don't get to only pick the issues you care about and expect the PR to be done! |
|
On 1/30/23 07:43, Mark Pizzolato wrote:
I still don't see an answer. I see a problem report. I've also seen a problem report from @pkoning2 , but no followup. I've discussed comments with @rcornwell It's not like I don't know how to write comments for source code control. Writing comments in that style was my choice, intended to provoke a discussion. I think comments should describe why something was done, not what was done.
True. That's why I've closed the PR and deleted the fork. Considering Paul and Richard's comments about building on Windows, less concrete suggestions; requiring a build using three compilers on MacOS; some line-ending issue in the makefile; all illustrate that this is not the project for me. I know when a project is forcing a newb to jump through hoops. |
All newb's jump through the same hoops and then happily move on. It's your choice to move out instead. Good Luck. |
|
I'm sorry I haven't had a chance to try your latest fixes -- day job gets in the way sometimes... This seemed like an interesting simulator. It's unfortunate you changed your mind about wanting to contribute it. Perhaps in the future... |
|
On 1/30/23 09:20, Paul Koning wrote:
I'm sorry I haven't had a chance to try your latest fixes -- day job
gets in the way sometimes...
As for the log comments, I'm not sure why it would be reasonable to
write those in a style entirely different from the convention set by
the project. Having worked on a bunch of open source projects, I know
that the rules may vary from one to the next, and they might be fairly
loose or not so much, but there always is an expected style and
contributions that don't follow these will get pushback. That's true
for GCC; it's true for SIMH. I can't see why that is an unreasonable
hoop.
This is the same discussion I had with Richard. I OBVIOUSLY KNOW HOW TO
WRITE A FREKIN COMMENT!
It was intended to provoke a discussion about why the comments were in
that style. All I got was contrails. I expected more from a group of
propeller heads. It's not a hill I want to die on.
Pro tip: document the comment style in the writing a simulator for simh
document. I don't read git comments when looking for interesting code. I
certainly didn't read them before creating the PR.
On the three compilers, I'm not sure why that should be required. I
would think the default (llvm, a.k.a., clang, typically masquerading
as "gcc") on MacOS should be sufficient.
It's not clear to me that it's required. Mark has been using them as
linters in a build environment dialed to 11. gcc is a toolchain
different from clang on the mac. One acquires (at least this one did)
gcc via brew. In this case, it was gcc-12. Apparently clang++ is along
for the ride in the Apple xcode toolchain. IDK. I can't remember the
last time I spent an extended period of time writing c. For the past few
decades it's been scripting languages. I certainly haven't written c
code on mac before this effort. The only recent compiled language on mac
is Rust. For that reason, I had no idea that clang++ was available.
But of course on Linux you'd be using GCC and on Windows MSVC, so
you're dealing with the need to write portable code no matter what.
Still no reveal of the secret sauce required to build on Windows. As
I've said before, I think it's source code changes; which is a bridge
too far.
Pro tip: list required compilers in the writing a simulator for simh
document.
This seemed like an interesting simulator. It's unfortunate you
changed your mind about wanting to contribute it. Perhaps in the
future...
There's no other simulator in its class in simh. Additionally, I think it's one of the few simulators that implements a modified Harvard architecture. I say "one of the few" as there may be others of that type.
|
|
Yes, it would be useful to have a "how to contribute" document. There is simh.doc, but that doesn't answer all the questions, obviously. |
|
Yes you do know how to write a comment. However without identifying the simulator the comment refers to how am I to determine which commits are important or not to my bug. With simulator name in first line of commit comment I can tell exactly which simulator this commit refers to. With a description of the change in the first line I can also tell whether this could be related to the bug I am trying to track down. Commit comments are not about provoking discussion they are about identifying to those who come along later what was changed. You are free to add in your provocative part of the commit on other lines of the commit other then the first two. |
|
@rcornwell Discussion is why I opened this PR in the first place. That's why I contribute to Open Source, and why I gravitated to this simulator in the first place. The Forth language is nothing without its freedom of expression. As I observed earlier, each practitioner brings their own CASE statement and disassembler. The Forth community is one whose email signatures range from the commercial to the curmudgeonly. That I took advantage of the PR, to make such provocative statements I claim ownership. Would that at least one here recognized the provenance of those lines w/o search engine amplification, how they obtain here. |
|
This update attempts to address the VC code and line feed endings issues. Have at it! |
|
Hello @jchimene , it looks like you reopened this PR, but pushed your changes to the master branch of your fork, instead of the rtx2001a branch. If you want to continue this PR, you can create a new rtx2001a branch in your repo and force push it. That being said, I did download the code from your fork, and was able to build and run the RTX2001A using both Visual C++ 2008 and Visual Studio 2022, running on Windows 10. Looks like this is getting close! Take care, |
|
@hharte Great to see! Mark threw some last minute changes over the transom, and it turns out I didn't do the makefile correctly w/r/t/ updates. I'll push a branch tomorrow. |
|
On Sunday, February 5, 2023 at 4:21 PM, @markpizz wrote:
Agreed
I'm not responsible for simh.doc Speaking of files I'm not responsible for: Would someone other than Mark please describe why I'm responsible for a file named "Simh.sln" for MSVC? Thanks. |
Well, I never said you were responsible for the doc. What I did say was that you copied a line or two of text as comments from that simh.doc into your rtx2001a_cpu.c. In the middle of the copied lines there was a single tab. That tab should be replaced by a couple of spaces. No other tabs appear in your source code. |
Yes, I see what you're referring to. |
You don't believe me? You're sounding adversarial again. You are adding a new simulator and hence there needs to be build instructions for that to support Visual Studio builds. Those instructions involve
If you're providing one of these files for new simulators, you need to provide both. In order to actually build on Windows, you need to be working with at least the .vcproj file. It seems that you just passed along the file that @hharte sent you without actually building since when I tried to build I needed to send you the various fixes that you subsequently added to the code. That IS NOT a problem. You don't have easy access to the Windows platform. If you're going to take the .vcproj file without testing, then you also need to take the updated simh.sln file. Please ignore everything I've said above since it came from me and I know nothing about this stuff. |
That's just too bad. I eventually figured out the reason for the .sln after asking the above. I appreciate that you act as the project linter; which is why I take your code revisions seriously. Can PR this merge? If not, please provide a list of bullet points to check using github-flavored markdown. Please no private comments re: this PR. |
|
I general, when a new simulator comes along or a very significant contribution, the contributors steps along the way would be squashed into one commit reflecting the general description of the contribution. Apart from squashing, others (@pkoning2 specifically) have some personal experience with actually using a simulator like this. If they're happy then a merge is good with one additional detail: Please update your github profile to include your full name. I sent you private messages to provide fixed/additional files which were easy as email attachments. |
|
@jchimene I believe I told you all the things that you needed to do to be compatible with moving your source into the main open-simh tree. Such as no tabs, dos format files etc. Personally I agree 100% with the no tabs. They cause no end of trouble when the tab stops are not the same as the author. I personally have adopted this standard in all my projects. Except were required like in make files. Most of these items are quickly implemented and are not that burdensome. I also had to go through these hoops when I started submitting simulators. |
|
One last thing which I've mentioned before. Please update your local git configuration to also have your full name rather than the jchimene name. Look through the commits on the repo and you'll see that everyone goes by their whole name.
|
I think we're there with the no tabs and dos format files. I can't see any other comments about those issues raised in #157 (comment) |
|
Like, I said, Tabs and CRLF issues are good. My other points are still to be addressed. |
The name thing I'm considering. I'm not sure I want my name associated in such a way. If ther are other issues, please put them in bullet poins. |
|
I really enjoy repeating myself. Here you go:
As @rcornwell said, hoops are what everyone has gone through, once they're addressed, then they are behind you. |
|
I just tried this, on Mac, with the rtx2001a.ini startup file. Entered "go" as instructed, nothing happens, no response to keyboard input. |
|
Well, that's not encouraging. This is definitely an alpha-level tactic, although some of step.ini will be a test to run during a build |
|
step.simh doesn't exist in the PR. And I noticed rtx2001a.ini tries to load appforth.hex which doesn't exist either. Missing files in the commit, perhaps? |
|
I think something is not right with the way GitHub is handling this PR, possibly because the original rtx2001a branch was deleted. This PR still shows 7 (old) commits, while https://github.com/jchimene/openSimh shows only two. @pkoning2 if you cherry pick the two commits from https://github.com/jchimene/openSimh, I think you’ll find the simulator is working. I’m not sure how to fix this, but opening a new PR is one way. |
|
ouch. sorry about that. |
I'd like to propose this as an addition to the simh project.
I don't see other examples of Forth chips. I think it represents an interesting use of the simh architecture.
It's still WIP.