wilkxus
<Bronze Donator>
- 519
- 210
Quite curious @a_skeleton_03, what exactly are you thinking of doing? Last idea was cool and worked out well heh.
Generally speaking I only see 2 potentially usefull options open :
I worked on some porting and migration projects in the 90s, some hefty (for the time) Mainframe projects that involved mixes of shell languages, scripts, 4GLsand compiled languages: the problem domain made it easy to auto translate a lot of the labor intesive coding, and hand craft/tweak the rest. The tools for the conversion and translation were hand crafted only for our applications though, not really reusable for anyone elses code. These days large applications just grow and get enhanced, rewritten and re-architected to suck up new hardware and software resources rather than porting.
(1) emulation
In general it makes no sense to translate unless you are trying to preserve an identical application (Docker?). I still have another assembly project like that from the 80s for *preserving* a game (the Original Bards Tale RPG from Commodore 64 . After stripping out copy protection it was a virtually 1:1 assembly port from original 8 bit 6502 to Motorolla 68k assembly (Atari ST), with hand tweaked *drivers*, if you could call it them, and bits in C, portions for video and sound and timing hardware.
Back then there were no software emulators yet but the beauty was it ran natively, much faster than C64, 100% without emulation, without disk swapping. Today only way I can run it is inside a software M68k emulator for Atari (Gemulator)
(3) more generic translation?
As for translation between languages (C to python).....moving between higher and lower level languages you are really alwas talking about more of a porting programming job than translation. You need to port & rewrite a lot unless you perhaps wanted to grandfather & emulate an application in its as close to original state on a new (and perhaps more portable platform or set of heterogeneous set pf hardware platforms). ie porting 8 bit assemby apps to C or Python....except then it makes more sense to use an existing emulaton layer.
Future! AI and neural learning networks!
This sort of auto translation stuff from one random language to another only makes sense if you were to develop a suite of smart, neural net learning AI type compilation & development tools (future tech cutting edge research stuff, with OSes and tools that do not exist yet).... in our heterogeneous computing future ..... it might eventually make sense, with enough software and demand for it ....unlikely without MUCH more inteligent software dev build and compile tools.
As I said bove, for GAMES it might make sense already today, to preserve, emulate them and make them accesible without destroying their artistic essence or uniqueness by mangling through a port..... but just for fun or kicks, not practical.
Generally speaking I only see 2 potentially usefull options open :
- emulation
- hand translate & port
- generic translate ...too complex/impractical
I worked on some porting and migration projects in the 90s, some hefty (for the time) Mainframe projects that involved mixes of shell languages, scripts, 4GLsand compiled languages: the problem domain made it easy to auto translate a lot of the labor intesive coding, and hand craft/tweak the rest. The tools for the conversion and translation were hand crafted only for our applications though, not really reusable for anyone elses code. These days large applications just grow and get enhanced, rewritten and re-architected to suck up new hardware and software resources rather than porting.
(1) emulation
In general it makes no sense to translate unless you are trying to preserve an identical application (Docker?). I still have another assembly project like that from the 80s for *preserving* a game (the Original Bards Tale RPG from Commodore 64 . After stripping out copy protection it was a virtually 1:1 assembly port from original 8 bit 6502 to Motorolla 68k assembly (Atari ST), with hand tweaked *drivers*, if you could call it them, and bits in C, portions for video and sound and timing hardware.
Back then there were no software emulators yet but the beauty was it ran natively, much faster than C64, 100% without emulation, without disk swapping. Today only way I can run it is inside a software M68k emulator for Atari (Gemulator)
(3) more generic translation?
As for translation between languages (C to python).....moving between higher and lower level languages you are really alwas talking about more of a porting programming job than translation. You need to port & rewrite a lot unless you perhaps wanted to grandfather & emulate an application in its as close to original state on a new (and perhaps more portable platform or set of heterogeneous set pf hardware platforms). ie porting 8 bit assemby apps to C or Python....except then it makes more sense to use an existing emulaton layer.
Future! AI and neural learning networks!
This sort of auto translation stuff from one random language to another only makes sense if you were to develop a suite of smart, neural net learning AI type compilation & development tools (future tech cutting edge research stuff, with OSes and tools that do not exist yet).... in our heterogeneous computing future ..... it might eventually make sense, with enough software and demand for it ....unlikely without MUCH more inteligent software dev build and compile tools.
As I said bove, for GAMES it might make sense already today, to preserve, emulate them and make them accesible without destroying their artistic essence or uniqueness by mangling through a port..... but just for fun or kicks, not practical.