Any one knows if Ada is used in James Webb Space Telescope software.
Either in the control systems or in the embeded software for the Telescope.
https://www.jwst.nasa.gov/
I sure hope they did not use javascript or Python or C for the software.
Since it was 30 years in developing, I would not dismiss QBasic...
"Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> writes:
Since it was 30 years in developing, I would not dismiss QBasic...Don't forget Forth! It was used on many space projects.
https://web.archive.org/web/19990125085748/http://forth.gsfc.nasa.gov/
I didn't realise there had been so many projects in Forth.
as it looked like we (Matra Marconi Space) might be forced to use the
RTX2010 as it was one of very few space qualified processors with
hardware floating point support. In the end we used the MA31750, with
Ada, instead.
John McCabe <john@mccabe.org.uk> writes:
I didn't realise there had been so many projects in Forth.
Much of Forth's early development was at the Kitt Peak observatory where
I think Charles Moore worked for a while, so it was popular with the astronomy community and maybe indirectly with the spaceflight community through there and JPL. As a more general matter, hardware designers (electrical engineers who sometimes have to muck with embedded software
but aren't really into programming as a topic) tend to like it because
of its simplicity and directness.
as it looked like we (Matra Marconi Space) might be forced to use the
RTX2010 as it was one of very few space qualified processors with
hardware floating point support. In the end we used the MA31750, with
Ada, instead.
Interesting. I hadn't heard of the MA31750 but it appears to be a 16
bit processor that implements the MIL-STD-1750A instruction set(!),
which I didn't know about either. Apparently it was made in the 1980s
but has since been superseded by SPARC architecture cpu's.
I wonder if targeting GCC to the RTX2010 might have been feasible.
Can I ask what Ada compiler you used for the MA31750? It looks like GCC supported the MA31750 until version 3.1, but I don't know whether GNAT existed then.
John McCabe <jo...@mccabe.org.uk> writes:
as it looked like we (Matra Marconi Space) might be forced to use the RTX2010 as it was one of very few space qualified processors with
hardware floating point support. In the end we used the MA31750, with
Ada, instead.
Interesting. I hadn't heard of the MA31750 but it appears to be a 16
bit processor that implements the MIL-STD-1750A instruction set(!),
which I didn't know about either. Apparently it was made in the 1980s
but has since been superseded by SPARC architecture cpu's.
I wonder if targeting GCC to the RTX2010 might have been feasible.
Can I ask what Ada compiler you used for the MA31750? It looks like GCC supported the MA31750 until version 3.1, but I don't know whether GNAT existed then.
On Monday, 27 December 2021 at 00:37:03 UTC, Paul Rubin wrote:
John McCabe <jo...@mccabe.org.uk> writes:
as it looked like we (Matra Marconi Space) might be forced to use
the RTX2010 as it was one of very few space qualified processors
with hardware floating point support. In the end we used the
MA31750, with Ada, instead.
The Ada compiler we used was the same as Nikolas; TLD.
Although Nikolas mentions Matra Marconi Space mandating TLD, that
would've come down from Dornier who'd apparently done a deal with
TLD.
Any one knows if Ada is used in James Webb Space Telescope software.
On 2021-12-28 12:24, John McCabe wrote:
[snip]
Although Nikolas mentions Matra Marconi Space mandating TLD, thatYes, a considerable part of our requirements came from Dornier via Matra Marconi Space (France). We sometimes had fun trying to understand how
would've come down from Dornier who'd apparently done a deal with
TLD.
the French had interpreted requirements written in English by the
Germans. The two other languages had left their imprints on the
"English" wording :-)
On Tuesday, 28 December 2021 at 10:59:36 UTC, Niklas Holsti wrote:
On 2021-12-28 12:24, John McCabe wrote: [snip]
Although Nikolas mentions Matra Marconi Space mandating TLD,Yes, a considerable part of our requirements came from Dornier via
that would've come down from Dornier who'd apparently done a deal
with TLD.
Matra Marconi Space (France). We sometimes had fun trying to
understand how the French had interpreted requirements written in
English by the Germans. The two other languages had left their
imprints on the "English" wording :-)
We didn't really have that problem. On TCIU most of our requirements
came from Dornier - > MMS-UK (ASAR instrument prime) - > Alcatel - >
MMS-UK (TCIU team). Both MMS-UK teams were in Portsmouth.
Alcatel were only there because of 'juste retour'*
and they didn't even seem to bother trying to interpret the MMS-UK
ASAR requirements, they just changed the front page to have
"Alcatel" on it. We basically had a shed-load of requirements placed
on us that had nothing to do with what the TCIU needed to do, and
Alcatel never did get round to formally specifying the bit we really
did need from them (the TCIU -> T/R Module - an Alcatel device -
interface) as far as I can remember!
It was good in a way, but Alcatel certainly, and possibly also
Alenia, played politics all the way through. We were required to go
through Alcatel to get them to clarify some of the requirements that
were relevant and had come from MMS-UK. As they had no idea what they
meant, Alcatel had to go to MMS-UK to get the clarification.
Fortunately Alcatel appeared to want to do as little work as possible
for their money so they'd just forward the clarification from MMS-UK
without bothering to try to understand it.
I'm sure lots of people have been in similar situations, but the
inefficiency could've been disastrous, especially as we (the MMS-UK
teams) had been working directly with each other on ASAR for years
before Alcatel were put in to split us up, and we used the same
canteen!
On 2021-12-31 12:26, John McCabe wrote:
We didn't really have that problem. On TCIU most of our requirements
came from Dornier - > MMS-UK (ASAR instrument prime) - > Alcatel - >
MMS-UK (TCIU team). Both MMS-UK teams were in Portsmouth.
Interesting :-). I had a similar, but inverse, experience in a later
project (SW for the Flexible Combined Imager instruments on the MTG satellites) where Thales Alenia Space (France) was both our customer for
the whole SW and our subcontractor for a part of the SW. It led to a
number of "direct" communications and decisions between the two TAS-F
teams that bypassed our team (in Finland) and of which we learned later.
But not much harm done, overall a good project.
Although splitting work up into several companies does easily make for inefficiency, in can also have the benefit of documenting stuff that otherwise might be lost in internal e-mails or face-to-face discussions.
That is, if the companies involved do their work properly, and don't act
as you describe for Alcatel. But perhaps the Alcatel technical people
did as well as they could to mitigate a poor higher-level decision, by
being basically a transparent conduit, as you describe.
John McCabe <jo...@mccabe.org.uk> writes:
I didn't realise there had been so many projects in Forth.
Interesting. I hadn't heard of the MA31750 but it appears to be a 16
bit processor that implements the MIL-STD-1750A instruction set(!),
which I didn't know about either. Apparently it was made in the 1980s
but has since been superseded by SPARC architecture cpu's.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 12:25:30 |
| Calls: | 6,645 |
| Calls today: | 5 |
| Files: | 12,190 |
| Messages: | 5,326,718 |