JOVIAL J73
- MIL-STD-1589C (USAF, July 1984)
- The dominant modern dialect.
- Full grammar implemented in the DMS JOVIAL Front End.
DMS, our deterministic toolkit that combines symbolic AI and enhanced compiler technology, runs the JOVIAL2C translator that converted 1.2 million lines of JOVIAL J73 to C for the Northrop Grumman B-2 Spirit Bomber Operational Flight Program. JOVIAL2C has been in production on defense workloads since 2009. Gen AI handles the adjacent work, like business rule extraction and test generation.
Trusted By
Northrop Grumman acquired an Enterprise Software Modernization License from Semantic Designs to run the JOVIAL2C translator on the B-2's Operational Flight Program. The OFP Refresh extended the bomber's mission life by re-hosting flight management software on modern processors. The JOVIAL2C tool has migrated additional OFP components since the initial engagement.
A second defense engagement shows the same translator pattern outside JOVIAL. A radar system running 650,000 lines of Fortran on VAX/VMS had to move to C++ on Linux. The internal team lacked the time, the Fortran resources, and a path off the aging VAX platform. We defined the Fortran source grammar and the transformation rules to C++, then built a C++ support library that replicated the VAX/VMS operating system features the application relied on. The conversion ran 100% automated and delivered in 10 months, well under the cost and timeframe of a manual rewrite.
Same engine, different source language. The radar engagement and the B-2 program both came down to defining a legacy language to DMS once, then letting the deterministic translator do the work at scale.
Every platform above represents an active sustainment program. As original JOVIAL engineers retire and 1750A tooling exits support, the migration decision moves from optional to inevitable.
Every JOVIAL J73 construct has a defined translation rule. The mapping is deterministic, reproducible, and auditable. The hard cases are the ones where J73 carries information C has no way to express: TABLE entries can be packed dense, medium or parallel, and the packing choice changes the memory layout the rest of the program depends on. We preserve the layout rather than the declaration.
| JOVIAL J73 | C target |
|---|---|
| ITEM declaration | typedef plus scalar variable |
| TABLE | struct or array of structs |
| BLOCK | translation unit (.c file) |
| COMPOOL module | .h header with compile-time conditional initializers |
| STATUS variable | enum type |
| BIT type | bit field or unsigned char |
| BYTE type | uint8_t |
| WORD type (1750A native) | uint16_t |
| FIXED with scale and range | scaled integer or fixed-point library call |
| FLOATING with scale | float or double with explicit scaling |
| REF (pointer-like) | C pointer |
| DEFINE | #define or static inline |
| Inline assembly | __asm__ block, target architecture-specific |
Target is C with GNU extensions as provided by GCC 3.0, which is what the shipped JOVIAL2C translator emits. Bit-precise declarations rely on GNU bit-field and __typeof__ extensions, so a strict C99 or MISRA C target is a scoped change to the back end rather than a compiler flag. Other C dialects produced under contract.
Original JOVIAL code assumes a 16-bit MIL-STD-1750A processor with specific word size, byte ordering, and floating-point representation. Translated C must replicate behavior on whatever target processor you pick.
JOVIAL programs share data through COMPOOL modules with implicit linkage rules. A COMPOOL declares the item, and every compilation unit that names it sees the same storage without an explicit extern, so ownership of the definition is not recorded anywhere in the source. C requires explicit header files and linker-resolved symbols. Mapping is mechanical but easy to get wrong by hand.
JOVIAL FIXED types carry explicit scale and range. Operations preserve precision according to formal rules. Naive translation to C int or float drops precision silently. Preserving the original arithmetic requires scaled-integer or fixed-point library mapping.
Flight software runs on hard real-time schedules. Translated C must hit the same timing budgets. Profiler validation and target-platform benchmarking are part of every project.
JOVIAL exposes bit-level memory operations that depend on processor byte order and word size.
Translated C uses bit fields, unions, and explicit byte-swapping where required.
We verify the translation at every phase of the pipeline, not only at the end:
The DMS toolkit emits a mapping report for every translated construct. Reviewers see the JOVIAL input and the C output side by side, with the transformation rule that produced it. Auditable and reproducible.
Syntax AuditTranslated C is built with the target compiler and toolchain you specify. Compiler warnings and errors are resolved before any runtime testing begins.
Static AnalysisThe translated C runs against the same input set as the original JOVIAL, with outputs compared for functional equivalence. We build the test framework alongside the translation and run it continuously through development.
Parity CheckWhere the program requires it, we produce traceability artifacts mapping translated C back to original JOVIAL and forward to requirements. Output structured for downstream DO-178B and DO-178C certification work.
Cert-ReadyThe verification work is heavy compared to commercial migrations. Defense buyers know this. The verification artifacts and process are what separate a translated codebase from a flying codebase.
Concrete artifacts, listed for RFP scoping:
Semantic Designs has engaged on classified and unclassified defense programs since the 1990s.
Cleared engineering work coordinated on a per-program basis.
Source code intake and handling procedures designed around ITAR and EAR requirements.
Customer-side classification controls respected throughout the engagement.
Translated C output structured for downstream DO-178B and DO-178C verification work.
Traceability artifacts produced where the program requires them.
Internal information handling aligned to current CMMC and NIST 800-171 expectations for defense
contractor work.
Customer-specific compliance requirements addressed in the engagement contract.
Four phases, scaled to defense program timelines:
Codebase intake (classification-appropriate), construct inventory, dialect detection, complexity report, fixed-price quote.
JOVIAL2C runs against a 50,000 to 100,000 line slice. Output compiled, tested against original, behavior verified.
depending on codebase size. Rolling module deliveries every 4 to 6 weeks.
Parallel behavioral testing against the original JOVIAL. DO-178 verification artifacts produced as required.
General questions
JOVIAL to C migration is the automated conversion of JOVIAL (Jules' Own Version of the International Algorithmic Language) source code into functionally equivalent C. The DMS-based JOVIAL2C translator supports MIL-STD-1589C (J73) JOVIAL as the source language and generates C with GNU extensions by default. Custom C dialects are available as required.
We fully support JOVIAL J73 (MIL-STD-1589C, USAF July 1984). J3, J3B-2, and J73/I (MIL-STD-1588) are supported under contract. Custom JOVIAL dialects used by specific defense programs or contractors can also be accommodated through DMS front-end customization.
A 500,000-line JOVIAL application typically requires 9–14 months, while multi-million-line defense systems may take 18–30 months. Projects generally include assessment, pilot translation, full conversion, and verification phases based on program requirements.
Pricing is determined per project rather than per line of code. Factors include codebase size, supported dialects, target processor, and required verification artifacts. A free assessment provides a fixed-price quote valid for 90 days.
Yes. We have supported classified and unclassified defense modernization projects for decades. Classified engagements are managed through the customer's contracting organization using appropriate security procedures and cleared engineering personnel.
Yes. Translated C can target modern architectures including PowerPC, ARM, x86-64, RISC-V, and other processors with a C compiler. The translation accounts for differences in endianness, word size, and floating-point behavior.
We compare timing characteristics between the original JOVIAL application and the translated C implementation. Where strict timing requirements exist, performance is validated, optimized when necessary, and confirmed through testing on the target hardware.
Existing JOVIAL test cases are translated alongside the production code. Test logic, expected outcomes, and pass/fail criteria are preserved, and legacy test frameworks can be adapted to modern C testing environments for regression validation.
Mixed-language environments are fully supported. Ada interfaces are preserved with compatible C
wrappers, while assembly code can be retained using inline __asm__ blocks where
appropriate. Existing language boundaries remain intact after migration.
Yes. The translated C is structured to support downstream DO-178B and DO-178C verification. Required artifacts such as traceability, structural coverage, and requirements mapping can be produced as part of the migration engagement.
Send your metadata. Complexity report and fixed quote in 10 business days.
.png)
info@semanticdesigns.com
