- Hi, Mike.
- I also am a RR fan, but my interests are more RR history (particularly books on railroads/railroading and steam), and also RR artifacts (signage, MOW items, and I also managed to buy a torpedo from an junk shop that didn't know what it was). I currently have around 2,800 titles in my RR (and steam) book collection and are in a text database (a flat file). All of the "steam" books contain a lot of information, of course, on steam locomotives. -- Gerard Schildberger (talk) 21:33, 10 August 2020 (UTC)
Hi Gerard! I should also mention that the company I work for is a railroad restoration company. In between figuring out a college major, I got involved with my local tourist railroad and worked there during summers becoming brakeman, conductor, and eventually diesel locomotive engineer, and an operations manager, but also had the opportunity at times to be fireman and hostler on the steam locomotives. This in turn led to where I am now. Our company is an ASME certified shop for building and repairing locomotive boilers, so we have a bit of a library ourselves (although I don't have an exact count on titles...)
Commodore BASIC Landmark
As of today, August 31, 2020, the alphabetical categorization of Commodore BASIC tasks now represents the entire alphabet. Woo hoo!
RR-GraphixGuy (talk) 22:49, 31 August 2020 (UTC)
Adjusting the Goals of Task "Machine Code"
Personal notes for future use in case I need them...
Citing the mission of RosettaCode from the landing page (emphasis added):
Rosetta Code is a programming chrestomathy site. The idea is to present solutions to the same task in as many different languages as possible, to demonstrate how languages are similar and different, and to aid a person with a grounding in one approach to a problem in learning another.
With that goal in mind, I find it interesting that the original task is limited to generating and executing opcodes for a very specific processor architecture (32-bit x86?). One of the things I like about RC is to compare the evolution of computer programming from a wide variety of systems and architectures for a single task. Just because a particular architecture or programming language isn't used in mainstream production anymore doesn't mean that nobody studies it, and as time goes on, some languages that were once considered popular will fall out of favor for newer, improved languages. The days of Commodore 64 programmers using BASIC to POKE machine code into memory and then call for its execution may not be common today, but it happened constantly during the machine's heyday and is part of its history. (Yes, it's the very reason I am addressing this issue now.)
What is the true goal of this task? To get the processor to execute the architecture-specific machine code given, or to illustrate how to get a processor to execute some native machine code within a higher level language, which still achieves the same end result (i.e. add two numbers together and show the result)?