MIPS programming - store a list of numbers

[ACLerok]

Hi, I am a completely newb to the MIPS assembly language and I'm having a bit of trouble with this one procedure. Basically, i want to have the user enter in a list of numbers. The user can keep entering in numbers but when -999 is entered, the user cannot enter in anymore numbers. This list of numbres is saved and then printed out in the orderthey were entered. I'm having trouble figuring out how to implement this. Can anyone help me out or have some code to put me in the right direction? Thank you in advance.

 

[Mark44]

Hi, I am a completely newb to the MIPS assembly language and I'm having a bit of trouble with this one procedure. Basically, i want to have the user enter in a list of numbers. The user can keep entering in numbers but when -999 is entered, the user cannot enter in anymore numbers. This list of numbres is saved and then printed out in the orderthey were entered. I'm having trouble figuring out how to implement this. Can anyone help me out or have some code to put me in the right direction? Thank you in advance.

This is an interesting question, if only because an unknown of input numbers have to be stored. Because how many numbers are to be entered isn't known, you can't just set aside a fixed amount of memory in the user data segment. Pushing the numbers onto the stack would be a possibility, but when you popped them off the stack, the numbers would be in the reverse order.

The only remaining technique that I can think of would be a linked list on the heap, with each node containing one input number and the address of the next node. After getting the first input value, save its address for later use, and then keep filling nodes with the input values and the value returned by the sbrk system service, which allocates memory from the heap.

I'll try to flesh this out in a later post.

 

[berkeman]

The user can keep entering in numbers but when -999 is entered, the user cannot enter in anymore numbers.

Because how many numbers are to be entered isn't known, you can't just set aside a fixed amount of memory in the user data segment.

And good programming practice is to have some limit on the maximum number anyway, even if you are allocating memory as you go. The platform you are progamming on usually won't have an infinite amount of memory available, so you need to decide what upper limit you want to put on that number. You may still dynamically allocate memory, but you should use the upper-limit check to keep from overflowing memory areas or getting failed memory allocation requests from the computer, IMO.

One of the hardest problems to debug in real-world applications is if you haven't been careful to put limitation checks on memory allocations. We once went round and round for days trying to figure out the problem with a new embedded radio program. Turns out we didn't put a hard upper limit on the size of an incoming packet, because we knew how big the packets were going to be. So we just allocated plenty of room for any incoming packet, and went on our merry way. Turns out that certain noise patterns could mimic the start of a valid packet, and once that happens, you are off to the races storing noise as a packet, looking for a packet termination character. Boom!

 

[Mark44]

The platform you are progamming on usually won't have an infinite amount of memory available, so you need to decide what upper limit you want to put on that number. You may still dynamically allocate memory, but you should use the upper-limit check to keep from overflowing memory areas or getting failed memory allocation requests from the computer, IMO.

That's a good point.
I wasn't thinking in terms of establishing a limit, since the input was going to come from user entry, and the user would likely get tired of entering numbers long before the heap memory was exhausted. Nevertheless, if the program was later modified to take input from, say, a large disk file of several GB, it would be crucial to have the program exit gracefully rather than fail due to lack of memory.