MIPS programming - store a list of numbers

Click For Summary

Discussion Overview

The discussion revolves around implementing a procedure in MIPS assembly language that allows a user to enter a list of numbers, which should be stored and printed in the order they were entered, terminating input when -999 is entered. The conversation explores memory management techniques suitable for handling an unknown number of inputs.

Discussion Character

  • Exploratory
  • Technical explanation
  • Debate/contested

Main Points Raised

  • One participant suggests that since the number of inputs is unknown, a fixed amount of memory cannot be allocated in the user data segment.
  • Another participant proposes using a stack for storing numbers but notes that this would reverse the order when popping them off.
  • A linked list on the heap is proposed as a possible solution, where each node contains an input number and the address of the next node.
  • Concerns are raised about the need for an upper limit on the number of inputs to prevent memory overflow, even with dynamic memory allocation.
  • A participant shares a personal experience highlighting the importance of implementing limitation checks on memory allocations to avoid debugging difficulties.
  • There is acknowledgment of the need for graceful program termination in cases of excessive input, especially if modified to read from large files.

Areas of Agreement / Disagreement

Participants express agreement on the necessity of managing memory effectively and the importance of setting limits on input. However, there is no consensus on the best approach to implement the procedure, with multiple competing views on memory management techniques.

Contextual Notes

Limitations include the assumption that user input will not exceed memory capacity, and the discussion does not resolve how to handle potential memory allocation failures.

ACLerok
Messages
194
Reaction score
0
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.
 
Technology news on Phys.org
ACLerok said:
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.
 
  • Like
Likes   Reactions: berkeman
ACLerok said:
The user can keep entering in numbers but when -999 is entered, the user cannot enter in anymore numbers.
Mark44 said:
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! o0)
 
berkeman said:
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.
 

Similar threads

  • · Replies 4 ·
Replies
4
Views
3K
  • · Replies 29 ·
Replies
29
Views
4K
  • · Replies 15 ·
Replies
15
Views
3K
  • · Replies 2 ·
Replies
2
Views
2K
Replies
65
Views
5K
  • · Replies 20 ·
Replies
20
Views
6K
  • · Replies 2 ·
Replies
2
Views
3K
  • · Replies 1 ·
Replies
1
Views
3K
Replies
1
Views
10K
  • · Replies 16 ·
Replies
16
Views
3K