SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

[Urwumpe]

That would mean mooooooooooooooore code to manage. Taking the scenario writing out of the user's hands by finishing SSU Workbench is IMO a better option.

Yes. But remember: The people who programm the workbench are human, too. I especially talk about me there. I am VERY human sometimes. :blush:

 

[GLS]

(for historical reference, this is the post that sent Urwumpe to the hospital)

So, the work on the ground side is pretty much done: the pads are more organized and the LCC can now insert holds when things aren't right, and the user can also stop the clock if he/she needs to go to toilet before launch :rofl:. Currently missing is the capability to recycle to T-9 minutes (but that will have to wait until the rest of the countdown is done), and the LCC MFD still needs some work to be ready for public consumption.

Now the RSLS. Unlike the ground side where I had to come up with logic to do what I think it does, we have flow charts for the RSLS with the correct sequence of events it does... the problem is getting those flow charts into code. In some places the flow is pretty "complex" and exceeds the if/else statement capability. One could break all the flow chart steps into (tiny) functions and these call/return statements would probably work. But that would mean 78 functions (if I counted well), with all the declarations/etc... it seems a bit too much "text overhead" compared with alternative: the goto statement.

(pause for Urwumpe to call 112)

Yes yes yes, I've heard all the warnings about the goto being the tool of the devil, and up until now I never really saw the need to use it, but it seems to be exactly what is needed to turn those flow charts into code. I just finished writing a "code skeleton" for maybe 30 steps and I found no (visible) problems with this approach. And if you're thinking I have no experience with gotos... you are right... I never used a goto in C/C++ but, I did some Assembly code, so I understand the "power" of it. One of the things I did was write a "1970s car game", where the user has to steer the car away from incoming walls, and the only crashes going on were when the car hit a wall. :lol:
So, can I go this way?

 

[Urwumpe]

it seems a bit too much "text overhead" compared with alternative: the goto statement.

(pause for Urwumpe to call 112)

Yes yes yes, I've heard all the warnings about the goto being the tool of the devil, and up until now I never really saw the need to use it, but it seems to be exactly what is needed to turn those flow charts into code. I just finished writing a "code skeleton" for maybe 30 steps and I found no (visible) problems with this approach. And if you're thinking I have no experience with gotos... you are right... I never used a goto in C/C++ but, I did some Assembly code, so I understand the "power" of it. One of the things I did was write a "1970s car game", where the user has to steer the car away from incoming walls, and the only crashes going on were when the car hit a wall. :lol:
So, can I go this way?

Well, NASA used goto as well, thus the nice flow-charts. Also, I am not allergic against gotos in general. :lol:

I just prefer gotos that are not named goto.

Often, break, continue or return statements are better alternatives there because they describe better what the goto does. Its still a nice goto in execution of course.

And if you really want to know what made me crazy (No, it was not Batman), imagine a single C99 function. Its 2800 lines of code long. It has a label "skip:" near its end. In various places under varying conditions, a "goto skip;" appears. You have TRACE log messages everywhere in development. But a bug appeared in production, with Log level INFO, you only know this function was entered with some input data and left with the wrong outputs. You have to debug this function.

In SSU, we can of course use exception handling in our general code. In the future GPC process bodies, I think staying close to the flowchart and using a HAL/S-like domain specific language to stay close to the macros used there is better for readability and verification. Thus: If there is a goto in the flow-chart, we should use a goto in code.

 

[GLS]

Well, NASA used goto as well, thus the nice flow-charts. Also, I am not allergic against gotos in general. :lol:

I just prefer gotos that are not named goto.

Often, break, continue or return statements are better alternatives there because they describe better what the goto does. Its still a nice goto in execution of course.

And if you really want to know what made me crazy (No, it was not Batman), imagine a single C99 function. Its 2800 lines of code long. It has a label "skip:" near its end. In various places under varying conditions, a "goto skip;" appears. You have TRACE log messages everywhere in development. But a bug appeared in production, with Log level INFO, you only know this function was entered with some input data and left with the wrong outputs. You have to debug this function.

In SSU, we can of course use exception handling in our general code. In the future GPC process bodies, I think staying close to the flowchart and using a HAL/S-like domain specific language to stay close to the macros used there is better for readability and verification. Thus: If there is a goto in the flow-chart, we should use a goto in code.

2800 lines? Atlantis.cpp alone has over 7800, and most of them don't have errors :lol:.

Anyway, what instructions are used isn't said. Here's a portion of the RSLS flow chart:

The code for a step would be:

step10:
    if (resumecountcomand)
    {
        // reset flags
        goto step12;
    }
    else
    {
        goto step11;
    }

step11:
    // etc...

In some places it's possible to avoid a goto, but as long as we are using it, I think it's better to do all the steps this way.

 

[Urwumpe]

2800 lines? Atlantis.cpp alone has over 7800, and most of them don't have errors :lol:.

Yes, but we also rarely have a single function in that CPP that exceeds 200 SLOC.

Anyway, what instructions are used isn't said. Here's a portion of the RSLS flow chart:

Well, I would not do it like that. Its ineffective. Better try understanding the command flow and implement it accordingly. By your example, about 95% of the gotos would not be needed because its an else branch or a following code block.

A comment like "//Ref: RSLS flow chart, BLOCK 11" would be better then in the code.

 

[GLS]

Well, I would not do it like that. Its ineffective. Better try understanding the command flow and implement it accordingly. By your example, about 95% of the gotos would not be needed because its an else branch or a following code block.

A comment like "//Ref: RSLS flow chart, BLOCK 11" would be better then in the code.

Yes, in most places we don't need a goto, but the beauty of this is that this code is pretty much final (unless we get actual GPC code), and by doing these individual goto steps we don't have to worry about introducing logic errors with our interpretation. Yes, there are lots of sequential steps, and we could comment out a bunch of labels and gotos, but leaving that to the compiler is probably a better idea.
Maybe in the, for example, SRB Sep Sequencer we can write the code without a single goto.... fine, but as long as we need it, I think we should go all the way and have all the steps explicitly as the example above.

 

[Urwumpe]

Yes, in most places we don't need a goto, but the beauty of this is that this code is pretty much final (unless we get actual GPC code), and by doing these individual goto steps we don't have to worry about introducing logic errors with our interpretation. Yes, there are lots of sequential steps, and we could comment out a bunch of labels and gotos, but leaving that to the compiler is probably a better idea.
Maybe in the, for example, SRB Sep Sequencer we can write the code without a single goto.... fine, but as long as we need it, I think we should go all the way and have all the steps explicitly as the example above.

Well, the compiler only optimizes as good as you explain the semantics to it. A break can be optimized better than a goto that does the same job, because the compiler can not always understand that the goto is just a "break in disguise". If you insert multiple gotos in places where the language/compiler does not expect it, you will even produce highly ineffective and unmaintainable code. They will be removed - but the code also won't be optimized as good as it could as a sequence without gotos.

Also, nothing stops us from referring to the drawing in the comments and use the comments for verifying the implementation as well. Remember, your solution would also not work well without comments, since a goto is absolutely unidirectional - you can't trace backwards and you have no stacktrace in debugging to help you.

Theoretically, we could even write special comments and process them before compilation in a verification step to detect if we are differing from the drawing.

 

[mrozigor]

Isn't state machine a better option? Even simple one as some kind of enum and switch to step handler. Or is it to time-consuming in case of SSU?

 

[GLS]

Well, the compiler only optimizes as good as you explain the semantics to it. A break can be optimized better than a goto that does the same job, because the compiler can not always understand that the goto is just a "break in disguise". If you insert multiple gotos in places where the language/compiler does not expect it, you will even produce highly ineffective and unmaintainable code. They will be removed - but the code also won't be optimized as good as it could as a sequence without gotos.

Also, nothing stops us from referring to the drawing in the comments and use the comments for verifying the implementation as well. Remember, your solution would also not work well without comments, since a goto is absolutely unidirectional - you can't trace backwards and you have no stacktrace in debugging to help you.

Theoretically, we could even write special comments and process them before compilation in a verification step to detect if we are differing from the drawing.

Well, all I can say is: don't worry! :lol: With the gotos, I think that following the flow chart is very easy and there's little to think about, so should all work well. I feel confident I can do this. I'll post the code here when I'm done.

 

[Urwumpe]

Well, all I can say is: don't worry! :lol: With the gotos, I think that following the flow chart is very easy and there's little to think about, so should all work well. I feel confident I can do this. I'll post the code here when I'm done.

Well, I am sure you will curse your own decision next year. :lol: But hey, I'll surely curse many of my own coding decisions next year as well.

---------- Post added at 03:50 PM ---------- Previous post was at 03:50 PM ----------

Isn't state machine a better option? Even simple one as some kind of enum and switch to step handler. Or is it to time-consuming in case of SSU?

Well, its a bit harder to read and maintain. But better than such a goto orgy for sure.

 

[mrozigor]

Well, its a bit harder to read and maintain. But better than such a goto orgy for sure.

I think that even simple loop is more readable and less error-prone than bunch of gotos.

void run() {
  switch (step) {
    case STEP_1:
      step1Handler();
      break;
    (...)
  }
}

void step1Handler() {
  (...)
  step = STEP_2;
}

int main() {
  while(1) {
    run();
  }
}

But I don't know how SSU work internally, so it's just random thought

 

[Urwumpe]

But I don't know how SSU work internally, so it's just random thought

Well, right now, we would need to use state machines to run longer software processes in Orbiters timestep system.

I work on implementing a limited multithreading environment for SSU, so GPC software executed by the same partition of the DPS can consist of up to 32 parallel tasks. (actually any number would work, but the PASS only allows 32 in its common memory structures)

In this case, you would have something like

void RCSSOP::run() {
     startio(rcsdataquery, &(pCPGNC->rcsdata), &rcsDataAvailable);
     waitFor(&rcsDataAvailable);

     if(pCPGNC->rcsdata.hepress < 5000) {
          annotateError("HE PRESS LOW");
     }
}

(But that might still change - I am just about 70% happy with the current state. And yes, the code is nonsense.)

The startio and waitfor statements would for example be used with the process context to synchronize the execution with Orbiters timesteps, so if you pause the simulation, the DPS software will pause as well and a faster machine running Orbiter will not result in the process running more often or IO needing less time.

 

[GLS]

But I don't know how SSU work internally, so it's just random thought

Feel free to look around https://sourceforge.net/p/shuttleultra/code/HEAD/tree/trunk/Orbitersdk/Space%20Shuttle%20Ultra/

 

[mrozigor]

In free time I'm planning to introduce myself to SSU codebase as well as migrate it to Git

 

[Donamy]

For DaveS,

The first pic is the OMSpod as it is on the shuttle. Make a straight vector along the Z axis (in AC3D coords) as shown. Then select the 2 verts and in rotation mode, set custom axis. Now select the groups to be rotated, then rotate them 45 degrees in the custom axis that was set. The groups should now be flat for texturing as shown in the second pic. When finished just choose the groups again and rotate them back. Don't forget to delete the line vector, or Orbiter will crash as a corrupted mesh.

 

[DaveS]

For DaveS,

The first pic is the OMSpod as it is on the shuttle. Make a straight vector along the Z axis (in AC3D coords) as shown. Then select the 2 verts and in rotation mode, set custom axis. Now select the groups to be rotated, then rotate them 45 degrees in the custom axis that was set. The groups should now be flat for texturing as shown in the second pic. When finished just choose the groups again and rotate them back. Don't forget to delete the line vector, or Orbiter will crash as a corrupted mesh.

I tried that and this is what I ended up with: https://www.dropbox.com/s/of6m0zjf6khudx2/Mismapped_default_OMS_pod.jpg?dl=0

That's not the new 5.0 OMS pod but actually the right OMS pod from the 4.2 mesh which I know is good. I tried to replicate the mapping on that first to verify the procedure with no luck.

 

[Donamy]

You have to choose, five different sections of the mesh to be textured. Front, Top, Left, Right and Back . Then with sizing and vertice manipulation and working the texture, you make it fit. It's not a simple task.

 

[DaveS]

Could you show on this screenshot of the OMS pod texture from the AC3D TCE which part of the tile texture corresponds to which mapping(Front, Left, Right and Top)?

https://www.dropbox.com/s/mugs4307rl32afs/AC3D_TextureEditor_OMS_pod.jpg?dl=0

 

[GLS]

Urwumpe, just to be sure: the processes "talk" to each other by setting flags in the COMPOOL, right? So, e.g., when process A wants process B to do something it sets flag X and each iteration, or when appropriate, process B checks flag X and if it is set it goes and does its thing... correct? I'm asking because the RSLS sets and resets a ton of flags and as the logic is not for me to change, I want to be sure that this is the way they talk, so that the flags can be reset correctly.

BTW: the step logic is all done with no issues, and I'm now "filling" them with their actions (what is currently possible anyway). I might have to improve/re-do the SSME SOP, and maybe others, before committing.

 

[Urwumpe]

Urwumpe, just to be sure: the processes "talk" to each other by setting flags in the COMPOOL, right? So, e.g., when process A wants process B to do something it sets flag X and each iteration, or when appropriate, process B checks flag X and if it is set it goes and does its thing... correct? I'm asking because the RSLS sets and resets a ton of flags and as the logic is not for me to change, I want to be sure that this is the way they talk, so that the flags can be reset correctly.

BTW: the step logic is all done with no issues, and I'm now "filling" them with their actions (what is currently possible anyway). I might have to improve/re-do the SSME SOP, and maybe others, before committing.

That is correct. You also have data exchange via public compools, but the processes are synchronized by event data types. Also, it is not just per iteration, you can signal and reset flags concurrently. Since RSLS is also programmed in HAL/S it should use the same synchronization statements. Events are 16 bit words with some special content actually, controlled by a few FCOS SVC calls.

As explanation there about how it works:

Lets say, process A waits for event F by a WAIT FOR F statement. It will pause with this state stored in the FCOS process descriptor.
Now, process B sets the flag by SIGNAL F. Instantly, the FCOS looks which process will execute next and finds A with the event F set.

Luckily, Windows used the same obsolete and ineffective communication scheme until recently, so we find all the support we need for this in the kernel.