Building my own computer and compiler

[Carlos Reves]

Good morning all!

As i said in my other thread, i'm reading Java How to Program: Early Objects, 10/E and found there another interesting exercise.
This one spans throughout the book and consists in these steps:

1. Build your own computer (Simpletron):

• a) Machine language programming (SML – Simpletron Machine Language);
• b) Build the Simpletron computer simulator;
• c) Extend and enhance SML.

2. Evaluate arithmetic expressions:

• a) Infix-to-Postfix converter;
• b) Postfix evaluator;
• c) Postfix evaluator modification.

3. Build your onw compiler:

• a) The Simple Language;
• b) Building a Compiler for the Simple Language;
• c) Optimizing the Simple Compiler;
• d) Modifications to the Simple Compiler;
• e) A Simple Interpreter.

There are many things i still have to read about before trying the second and third blocks of exercises, so i'll stick with the first one, especially its first 2 exercises.

I didn't code nothing yet because i want to start organizing ideas on how to approach the development of this code. So, what i'm going to ask you guys is a little help on this task. In the next posts i'll put the exercises.

[Liutauras Vilda]

This sounds like a very interesting programming task.

[Carlos Reves]

Here is 1.a):

(Machine-Language Programming) Let’s create a computer called the Simpletron. As its name implies, it’s a simple machine, but powerful. The Simpletron runs programs written in the only language it directly understands: Simpletron Machine Language (SML).
The Simpletron contains an accumulator—a special register in which information is put before the Simpletron uses that information in calculations or examines it in various ways. All the information in the Simpletron is handled in terms of words. A word is a signed four-digit decimal number, such as +3364, -1293, +0007 and -0001. The Simpletron is equipped with a 100-word memory, and these words are referenced by their location numbers 00, 01, …, 99.
Before running an SML program, we must load, or place, the program into memory. The first instruction (or statement) of every SML program is always placed in location 00. The simulator will start executing at this location.
Each instruction written in SML occupies one word of the Simpletron’s memory (so instructions are signed four-digit decimal numbers). We shall assume that the sign of an SML instruction is always plus, but the sign of a data word may be either plus or minus. Each location in the Simpletron’s memory may contain an instruction, a data value used by a program or an unused (and so undefined) área of memory. The first two digits of each SML instruction are the operation code specifying the operation to be performed. SML operation codes are:

Operation code	Meaning
Input/output operations:
final int READ = 10;	Read a word from the keyboard into a specific location in memory.
final int WRITE = 11;	Write a word from a specific location in memory to the screen.
Load/store operations:
final int LOAD = 20;	Load a word from a specific location in memory into the accumulator.
final int STORE = 21;	Store a word from the accumulator into a specific location in memory.
Arithmetic operations:
final int ADD = 30;	Add a word from a specific location in memory to the word in the accumulator (leave the result in the accumulator).
final int SUBTRACT = 31;	Subtract a word from a specific location in memory from the word in the accumulator (leave the result in the accumulator).
final int DIVIDE = 32;	Divide a word from a specific location in memory into the word in the accumulator (leave result in the accumulator).
final int MULTIPLY = 33;	Multiply a word from a specific location in memory by the word in the accumulator (leave the result in the accumulator).
Transfer-of-control operations:
final int BRANCH = 40;	Branch to a specific location in memory.
final int BRANCHNEG = 41;	Branch to a specific location in memory if the accumulator is negative.
final int BRANCHZERO = 42;	Branch to a specific location in memory if the accumulator is zero.
final int HALT = 43;	Halt. The program has completed its task.

The last two digits of an SML instruction are the operand—the address of the memory location containing the word to which the operation applies. Let’s consider several simple SML programs.
The first SML program reads two numbers from the keyboard and computes and displays their sum;

Location	Number	Instruction
00	+1007	(Read A)
01	+1008	(Read B)
02	+2007	(Load A)
03	+3008	(Add B)
04	+2109	(Store C)

The instruction +1007 reads the first number from the keyboard and places it into location 07 (which has been initialized to 0). Then instruction +1008 reads the next number into location 08. The load instruction, +2007, puts the first number into the accumulator, and the add instruction, +3008, adds the second number to the number in the accumulator. All SML arithmetic instructions leave their results in the accumulator. The store instruction, +2109, places the result back into memory location 09, from which the write instruction, +1109, takes the number and displays it (as a signed four-digit decimal number). The halt instruction, +4300, terminates execution.
The second SML program reads two numbers from the keyboard and determines and displays the larger value. Note the use of the instruction +4107 as a conditional transfer of control, much the same as Java’s if statement.

Location	Number	Instruction
00	+1009	(Read A)
01	+1010	(Read B)
02	+2009	(Load A)
03	+3110	(Subtract B)
04	+4107	(Branch negative to 07)
05	+1109	(Write A)
06	+4300	(Halt)
07	+1110	(Write B)
08	+4300	(Halt)
09	+0000	(Variable A)
10	+0000	(Variable B)

I need to go for a couple of hours. But when i come back i'll post the second exercise and my thoughts on how to approach them.

[Junilu Lacar]

This one exercise is enough to make this a very long thread. I suggest you focus on this problem first. If you're going to post the second exercise, please do it in a different thread.

[Junilu Lacar]

This first exercise will be easier for you to understand if you have some idea of how programs work at a very low level. Registers and opcodes (short for operation codes) are terms that are directly related to the internals of a computer and are about as close as you'll get to actually working directly with its hardware. Registers are the heart of a CPU and opcodes form the instruction set that it recognizes.

Search for assembly language instructions to see examples of real assembly language programs. Some of the links that search brings will have diagrams that help you visualize what registers are, what they're for, and how they work.

[Liutauras Vilda]

I encourage you as one of the starting points to draw an UML class diagram in order to get an idea what you're most likely going to deal with. In order to get that, you'll need probably to accomplish step 1 and step 2 from below.

1. Think what classes you may need to represent the Simpletron and its components. To identify classes look for the nouns in text, i.e.: Machine, Instruction, ... look for other (notice I started class names with an upper case, this is how class names supposed to start in Java, but I presume you know that already).
1.1. When thinking about the instructions, think what all instructions may have in common, so you may want to make one as a generalised and other instructions to derive from it, where each of it does some certain operation.

2. Similarly think about the verbs, which should represent your methods/operations your classes/objects do. i.e.: perform/execute instruction... look for other (I took randomly first verb I noticed, it may or may not relevant, that is for you to workout).

Is it enough to start thinking where you may start?

[Carlos Reves]

Liutauras Vilda wrote:This sounds like a very interesting programming task.

I thought that too Liutauras! A good and interesting task for me to learn new things...

Junilu Lacar wrote:This one exercise is enough to make this a very long thread. I suggest you focus on this problem first. If you're going to post the second exercise, please do it in a different thread.

I thought on posting the first 2 because they are connected with each other. But will do like you asked Junilu.

Junilu Lacar wrote:This first exercise will be easier for you to understand if you have some idea of how programs work at a very low level. Registers and opcodes (short for operation codes) are terms that are directly related to the internals of a computer and are about as close as you'll get to actually working directly with its hardware. Registers are the heart of a CPU and opcodes form the instruction set that it recognizes.

Search for assembly language instructions to see examples of real assembly language programs. Some of the links that search brings will have diagrams that help you visualize what registers are, what they're for, and how they work.

Although i never ever tried to learn assembly, i already had the curiosity about how things are done inside the processor so i've allready read before about registers (EAX, EBX, and so on) and opcodes. It's not easy to understand (at least for me) how all things are processed internaly by the processor, but i got a slight view on them.

Liutauras Vilda wrote:I encourage you as one of the starting points to draw an UML class diagram in order to get an idea what you're most likely going to deal with.

Never did an UML diagram. Read about it but never really used it. And i have a little problem with that because i can't install programs here were i'm working. So does anyone know a portable version of an UML program?

Liutauras Vilda wrote:In order to get that, you'll need probably to accomplish step 1 and step 2 from below.

1. Think what classes you may need to represent the Simpletron and its components. To identify classes look for the nouns in text, i.e.: Machine, Instruction, ... look for other (notice I started class names with an upper case, this is how class names supposed to start in Java, but I presume you know that already).
1.1. When thinking about the instructions, think what all instructions may have in common, so you may want to make one as a generalised and other instructions to derive from it, where each of it does some certain operation.

2. Similarly think about the verbs, which should represent your methods/operations your classes/objects do. i.e.: perform/execute instruction... look for other (I took randomly first verb I noticed, it may or may not relevant, that is for you to workout).

I started to think about it already. To be honest since this exercise is about processing SML, i thought that one class would be enough and it could be called SMLProcessor. In the second exercise there will be more: the Simpletron computer itself and a SML loader at least.
But this one is going to be the execution part of it i think. As for the instructions part there is already a natural division of them in the exercise: input/output, load/store, arithmetic and transfer of control intructions. These are, also most of the verbs i think will be needed to code the methods.

Liutauras Vilda wrote:Is it enough to start thinking where you may start?

More than enough...    

[Carlos Reves]

And thanks guys for the inputs.

[Liutauras Vilda]

...i can't install programs here... So does anyone know a portable version of an UML program?

Pencil and piece of paper.

[Carlos Reves]

Ok... I've been trying to get some UML done... So far i have this:
Class Diagram
(it's a jpeg image. Couldn't put it here directly...)

Thanks
Best regards
Carlos

[Junilu Lacar]

While I'll occasionally use diagrams to help me visualize the "big picture" of a design I have in mind, I'll very seldom if ever go into that much detail.  If you look at examples of high-level context diagrams, that's about as much detail as I go into when diagramming.  In my opinion, going into too much detail from the start is a trap. This boxes you into a "solution" that hasn't even been proven yet.  Then it leads to you want to create a solution based on that detailed design. The more details you have, the longer it takes for you to complete that initial solution. By the time you do have something that runs, you've probably already made compromises or have discovered that the initial design idea had a number of flaws. But since you've already spent a lot of time writing code based on that flawed design, you grit your teeth and keep pushing forward, trying to prove that your initial ideas were correct.

This is a vicious cycle.

On the other hand, if you start out with a generally nebulous picture, without much detail, then set out to discover what those details are by using tests and actual working code to prove, one bit at a time, that parts of your design work, then you're not inclined to get trapped in the mindset that creates that vicious cycle. This is what I have found is one of the biggest advantages of Test-Driven Development.  TDD is based on the premise that your initial design idea is flawed somehow and that working software and actual code are the best ways to reveal and flush out the flaws in your understanding of how the system should be structured and built.

[Junilu Lacar]

Incremental and iterative development techniques like TDD also have the advantage of allowing you to throw away design ideas that turn out to be not so good after all. These initial diagrams are just plans. No plan, no matter how well thought out, survives first contact with the enemy. This is true with software designs as well. The enemy is the reality as defined by working (or not working), running code.  That's the best way to prove or disprove the correctness of a design idea, by seeing if it actually works when it's coded out.

[Junilu Lacar]

Carlos Reves wrote:I've been trying to get some UML done... So far i have this:
Class Diagram

I took a closer look at that diagram and I can already spot some problems with the structures you've planned out. This is the problem with coming up with too many details too early.

Read the Essays by Jack Reeves on how Code is Design -- these are good ideas and I have found them to be true; you can't rely on diagrams for detailed designs. The code is the detailed design and only when you have running, working code will you be able to see the intricacies that are involved in the software design and what you can do to improve on it.

[Liutauras Vilda]

@OP

At this stage, I'm less strict on diagrams. Maybe I just use UML as a vague term. I too don't mean to code in a form of UML, but as a very starting point it helps. Simply just some sketch with pencil on a piece of paper some classes you may need to consider to start with, that is it.

Now that Junilu said not to take too big bite, you seemed to be taken some parts most likely from the other parts and added to your diagram.

Can you think of a smallest part (screw) in your program which you can start with? I can find it in very beginning of specification and which is probably very overcompliated in your diagram.
Beware, I maybe wrong in my initial thinking too.

[Junilu Lacar]

A slight modification to Liutauras' suggestion to start with the smallest part: start with what you know or what you were given. Go back over the requirements and identify the things you definitely will have. You already have some elements in your diagram. One problem I saw in your diagram is you have things duplicated all over the place. For example, I'm not sure what your thought process was in having multiple classes have memory as a field but that is definitely wrong, especially some of those classes that you gave that field to.

[Liutauras Vilda]

When I said you most likely over-complicated some parts in diagram, particularly I had in my mind at that time - SimpletronRegisters.

Now think for a moment:
1. Do the registers really maintain the counter of the instructions?
2. Do the registers really need to know operation code?
3. Do the registers need to know operands?
4. Do the registers do all those operations?

I won't give you a last question I'm holding in my mind at the moment as it would become obvious, that is for you to think for a moment.

Wait, let's go back to yesterday.. it seems you didn't acknowledge that.

Junilu Lacar wrote:Search for assembly language instructions to see examples of real assembly language programs. Some of the links that search brings will have diagrams that help you visualize what registers are, what they're for, and how they work.

Now that this thread has been added to General Java, it gives an idea that this task isn't a plug N play thing.

For a kick off, I'd suggest you read what Junilu suggested, as I personally see this as a closest information you may need for your earliest task in this problem.

[Norman Radder]

This sounds like an interesting project.  I was a main-frame assembly coder most of my working career.  Since then I've played with some machine simulators in C++ and Java.
I'm adding this post so I can keep up-to-date on this project.

[Carlos Reves]

Good morning all.

First i want to thank all for the replies!
When i did that diagram i was just trying to "visualize" possible classes. Maybe i went too far and even did it wrong but i was simply starting.
I think that the intent of this exercises isn't to go very deep in the machine language (SML). If you read the second exercise, there are many things said there that concern to how to deal with the SML in the computer simulation.
I've started a GitHub repository for this and i've uploaded there a PDF file with the first exercises if you don't mind taking a look.
I've tried to code something already for the first 2 exercises and added 2 text files with the SML instructions that are provided by them. I know that they ask to input the instructions thru keyboard but i tried to change that to a solution that reads from the files instead.
The classes i made are:

SMLProcessor - Processes the instructions loaded from file.

SMLLoader - Loads the instructions from file.

Simpletron - The computer simulation. Didn't add all those messages asked by the exercise.

I didn't yet tested the situations when the input isn't correct nor made a test suite (didn't have time). But if everything is correct in the file, it works.
The link for the git repository is here.

EDIT: The code is not commented yet... Sorry for that. And i know that the way i'm dealing with the exceptions isn't consistent but i'll try to fix that in the future.

Thanks

Best regards
Carlos

[Junilu Lacar]

So you went ahead and coded up the second exercise without trying to write the Simpletron assembly language programs required by the first exercise? I thought that was what your text files would be but I guess not. You'd have three more text files if you complete exercise 1.

[Carlos Reves]

Junilu Lacar wrote:So you went ahead and coded up the second exercise without trying to write the Simpletron assembly language programs required by the first exercise? I thought that was what your text files would be but I guess not. You'd have three more text files if you complete exercise 1.

I will do those also. But there were many question being made about why the news of those registers  for example, so yes... I coded the minimum needed to test the SML i'll write.

[Junilu Lacar]

1. I don't see much of a need to comment your code. It is pretty well-written and self-documenting. Good job on that.

2. I think you may have gone a bit too far with externalizing the memory array but it's not too bad right now that it can't be fixed.

[Junilu Lacar]

Let me explain what I meant by going too far and externalizing the memory array. The caveat here is that you have to remember, I'm always thinking about object-orientation. I don't like the idea of a raw data structure being floated and passed around like a ball. I like to keep data encapsulated.

Per the requirements, a Simpletron is supposed to have a fixed amount of memory: 100 words.  So, I would have expected to see something like this:

public class SimpleTron {
    private static final int MEMORY_SIZE = 100;
    private final int[] memory = new int[MEMORY_SIZE];

    ...
}

or maybe even something like this:

public class SimpleTron {

    private final int[] memory;

    public SimpleTron(int memorySize) {
         memory = new int[memorySize];
    }
 
    ...
}

To load a program, I imagine doing something like this:

     SimpleTron computer = new SimpleTron();  // or new SimpleTron(100);

     SMLLoader loader = new SMLFileLoader();  // or new SMLInteractiveLoader();
     computer.loadProgram(loader);

Then in the SimpleTron.loadProgram() method:

public void loadProgram(SMLLoader loader) {
      clearProgram();

      int location = 0;
      while (loader.hasNext()) {
            ... // boundary exception checks 

            memory[location++] = loader.next();
      }
}

[Junilu Lacar]

Carlos Reves wrote:But there were many question being made about why the news of those registers  for example

I don't get what you mean by that.

[Junilu Lacar]

I always like to imagine a "conversation" going on between objects. So, the conversation that happens when loading an SML program is something like this:

Director (e.g., the OS kernel): SimpleTron, use this Loader to initialize yourself with a new program.

SimpleTron: Ok. Hey, Loader, do you have another instruction?

Loader: Yes...  (or if No, we're done)

SimpleTron: Ok, let me check if I can still take on more instructions...
(errors out if no capacity to take more instructions)

SimpleTron: Ok, I'm still good. Loader, give me your next instruction.

Loader: Here you go.

SimpleTron: (takes instruction and puts it in the next open address in memory)

(repeat from step where SimpleTron asks Loader if it has more instructions)

[Carlos Reves]

Junilu Lacar wrote:1. I don't see much of a need to comment your code. It is pretty well-written and self-documenting. Good job on that.

Thanks Junilu. I just realised it's very pleasant when you don't have remarks on my code... Not even in the variable names...

Junilu Lacar wrote:2. I think you may have gone a bit too far with externalizing the memory array but it's not too bad right now that it can't be fixed.

I get what you are saying after your post next to this one. I'm still fiding it hard to think in an object oriented way... My earlier diagram shows that clearly i think. I'll take a look at your examples and your explanation on the "conversation" between objects to see if i can improve my way of thinking about these things.

Junilu Lacar wrote:

Carlos Reves wrote:But there were many question being made about why the news of those registers  for example

I don't get what you mean by that.

I was just refering to this post by Liutauras:

Liutauras Vilda wrote:When I said you most likely over-complicated some parts in diagram, particularly I had in my mind at that time - SimpletronRegisters.

Now think for a moment:
1. Do the registers really maintain the counter of the instructions?
2. Do the registers really need to know operation code?
3. Do the registers need to know operands?
4. Do the registers do all those operations?

I won't give you a last question I'm holding in my mind at the moment as it would become obvious, that is for you to think for a moment.

I just went with all those registers and those names because they are the exercise specifications.

Best regards
Carlos

[Junilu Lacar]

Carlos Reves wrote:

Junilu Lacar wrote:1. I don't see much of a need to comment your code. It is pretty well-written and self-documenting. Good job on that.

Thanks Junilu. I just realised it's very pleasant when you don't have remarks on my code... Not even in the variable names...

Well, don't get too cocky, now. It's still early.

[Carlos Reves]

Junilu Lacar wrote:

Carlos Reves wrote:

Junilu Lacar wrote:1. I don't see much of a need to comment your code. It is pretty well-written and self-documenting. Good job on that.

Thanks Junilu. I just realised it's very pleasant when you don't have remarks on my code... Not even in the variable names...

Well, don't get too cocky, now. It's still early.

Right... Won't be! But still it's good!

Ok then. Already made the first 2 SML programs. First one:

Use a sentinel-controlled loop to read 10 positive numbers. Compute and display their sum.

Here is the program in SML:

Location	Instruction	Comments
00	1009	Read an integer
01	2009	Load the integer to accumulator
02	4207	Sentinel can be zero, so branch to end the loop if it's entered
03	4107	Sentinel can also be a negative number
04	3010	Add the number to the sum
05	2110	Store the sum
06	4000	Repeat process
07	1110	Write the sum
08	4300	End the program
09	0000	Location for input integer
10	0000	Location for sum

Now the second one:

Use a counter-controlled loop to read seven numbers, some positive and some negative, and compute and display their average.

Here it is:

Location	Instruction	Comments
00	2016	Load initial counter to accumulator
01	2118	Store current counter value
02	1019	Read an integer
03	2019	Load integer to accumulator
04	3020	Add the number to the sum
05	2120	Store the sum
06	2018	Load current counter to accumulator
07	3117	Decrement counter
08	4211	If counter == 0 end loop
09	2118	Store current counter value
10	4002	Repeat the process
11	2020	Load the sum to accumulator
12	3216	Divide the sum by the count of numbers entered
13	2121	Store the average of the numbers
14	1121	Write the average
15	4300	End program
16	0007	Initial value for counter
17	0001	Counter decrement
18	0000	Location for current counter
19	0000	Location for input integer
20	0000	Location for sum
21	0000	Location for average

Going to a meeting in half an hour so no time to do the third. But i uploaded the 2 text files to Git: SumPositiveIntegers.txt and AverageOfNumbers.txt.

Best regards
Carlos

[Junilu Lacar]

That first requirement to "use a sentinel-controlled loop to read 10 positive numbers" seems ambiguous to me. If it's a purely sentinel-controlled loop, then there's no telling how many valid positive numbers will be entered before a sentinel value is entered. It could be less than 10, or 10, or more than 10. So, are you supposed to mix the logic, watch for a sentinel but don't terminate until the user has entered exactly 10 positive numbers? Of do you just trust the user to enter 10 positive numbers and then a sentinel value?

The second requirement is more reasonable.

[Carlos Reves]

Junilu Lacar wrote:That first requirement to "use a sentinel-controlled loop to read 10 positive numbers" seems ambiguous to me. If it's a purely sentinel-controlled loop, then there's no telling how many valid positive numbers will be entered before a sentinel value is entered. It could be less than 10, or 10, or more than 10. So, are you supposed to mix the logic, watch for a sentinel but don't terminate until the user has entered exactly 10 positive numbers? Of do you just trust the user to enter 10 positive numbers and then a sentinel value?

Yeah i thought about that also! And since they don't tell nothing more, i did a version like "input positive integers until a sentinel is entered and then print their sum".

[Junilu Lacar]

Aside from the ambiguity in the first program requirements, those SML programs look pretty good to me.

[Carlos Reves]

Junilu Lacar wrote:Aside from the ambiguity in the first program requirements, those SML programs look pretty good to me.

Thanks. But honestly didn't use a true sentinel value. With the current limited capabilities of the SML there is no way to "inform" the user about the sentinel value. So i used the <=0 values as sentinels since we want to sum only positive integers.

[Junilu Lacar]

Carlos Reves wrote:But honestly didn't use a true sentinel value. With the current limited capabilities of the SML there is no way to "inform" the user about the sentinel value. So i used the <=0 values as sentinels since we want to sum only positive integers.

I think that was a perfectly reasonable choice.

[Knute Snortum]

I suspect you will have problems with this code in SMLProcessor.java:

case READ:
	Scanner scan = new Scanner(System.in);
	System.out.print ("Enter an integer: ");
	memory[operand] = scan.nextInt();
	instructionCounter++;
	scan.close();
	break;

I think the second time you will not be able to open System.in again.  Two things I would recommend: Open a Scanner object only once and don't close it.  Your IDE may complain of a resource leak, but you can ignore this.

[Junilu Lacar]

What's more, hard-coding it to a Scanner that's associated with System.in severely limits your ability to test. If this code were instead just programmed to a Scanner and didn't care where the Scanner was getting input, you could plug in a Scanner that was reading from non-interactive sources and you could run tests much faster.

[Carlos Reves]

Knute Snortum wrote:I suspect you will have problems with this code in SMLProcessor.java:

case READ:
	Scanner scan = new Scanner(System.in);
	System.out.print ("Enter an integer: ");
	memory[operand] = scan.nextInt();
	instructionCounter++;
	scan.close();
	break;

I think the second time you will not be able to open System.in again.  Two things I would recommend: Open a Scanner object only once and don't close it.  Your IDE may complain of a resource leak, but you can ignore this.

Thanks for the tip knute. I used it like that and all went well even when it asked for 10 integers in a row... But i'll take that in consideration. I made it like that because i thought that would be a waste of resources having it always open, but obviously i was wrong it seems.

Junilu Lacar wrote:What's more, hard-coding it to a Scanner that's associated with System.in severely limits your ability to test. If this code were instead just programmed to a Scanner and didn't care where the Scanner was getting input, you could plug in a Scanner that was reading from non-interactive sources and you could run tests much faster.

Ok... Didn't know this also. So i should open it like this?

Scanner scan = new Scanner();

But then i need to figure out how to tell the scanner that the input is from keyboard... Have to read some about Scanner class...

Junilu Lacar wrote:That first requirement to "use a sentinel-controlled loop to read 10 positive numbers" seems ambiguous to me. If it's a purely sentinel-controlled loop, then there's no telling how many valid positive numbers will be entered before a sentinel value is entered. It could be less than 10, or 10, or more than 10. So, are you supposed to mix the logic, watch for a sentinel but don't terminate until the user has entered exactly 10 positive numbers? Of do you just trust the user to enter 10 positive numbers and then a sentinel value?

I've been thinking about this Junilu and what if the sentinel isn't supposed to be entered by the user? I mean something like this in java:

boolean notTenYet = true;
int n = 10;
while (notTenYet)
{
    int numberEntered = scan.nextInt();
    // Do something with the number entered.
    if (--n == 0)
    {
        notTenYet = false;
    }
}

This would be a sentinel controled loop to enter 10 integers right?

Best regards
Carlos

[Junilu Lacar]

No, that would be a counter-controlled loop. I think specifying 10 integers to be entered for a sentinel-controlled loop was a mistake that the authors and editors overlooked.

[Junilu Lacar]

Regarding the scanner, no, you wouldn't even create the Scanner in the class that uses it, you'd have it provided from outside, either as a parameter to the constructor or via a setter. Your Scanner basically becomes a field. Read about dependency injection.

[Carlos Reves]

Junilu Lacar wrote:No, that would be a counter-controlled loop. I think specifying 10 integers to be entered for a sentinel-controlled loop was a mistake that the authors and editors overlooked.

Oh... Ok... So "Sentinel" always means "from user input". Got it.

Junilu Lacar wrote:Regarding the scanner, no, you wouldn't even create the Scanner in the class that uses it, you'd have it provided from outside, either as a parameter to the constructor or via a setter. Your Scanner basically becomes a field. Read about dependency injection.

Got it. Will do the reading...

[Junilu Lacar]

A sentinel is a value that has a specific meaning. In this case, it means "no more values," and -1 or 0 is appropriate because neither are valid data values for the requirement to add positive numbers.

[Carlos Reves]

Done with the third SML exercise.

Read a series of numbers, and determine and display the largest number. The first number read indicates how many numbers should be processed.

Here it is:

Location	Instruction	Comments
00	1016	Input the total number of integers (counter)
01	1017	Input an integer
02	2018	Load maximum to accumulator
03	3117	Subtract the entered number
04	4110	If result < 0 goto 10
05	2016	Load counter to accumulator
06	3115	Decrement counter
07	4213	If counter == 0 end loop and goto 13
08	2116	Store the counter
09	4001	Repeat input process
10	2017	Load input integer to accumulator
11	2118	Store it as new maximum
12	4005	Goto 05 to decrement counter
13	1118	Write the maximum
14	4300	End Program
15	0001	Counter decrement value
16	0000	Location for counter
17	0000	Location for input integer
18	0000	Location for maximum

I've uploaded to GitHub the file MaximumSeveralNumbers.txt with it.

Best regards
Carlos