the computing theory leads to math, but....

the asm and c leads to english mnemonics, then....

what langage can be used to cover every use cases when dealing with practical programming?

my opinion is a set of transparent formulaes, where every single expression can be viewed as its asm and c equivalent when it's writen.

but how to do it?

when dealing with maths, asm have really a lot of solutions.
and when dealing with computing, maths also have a lot of solutions.

then, to make a sort of UASM, the first thing is to design a set of atomic operations, commons to every cpus.

the only thing not universal would be the binary, but it's not a problem if the compiler is easy to use, and the binary easy to load.


now, i'd like to find a way to write programs for any platform, without c/c++ boring construct, or specific asm stuff.

the only way is a U langage.

what do you think about it?

I think you meet a problem there. You end up with a very tiny set of primitives to work with, and then you can't exploit the full instruction set.

the compiler converts every universal instruction in the target specific instruction(s).

and any instrcution from any platform can be integrated to th Uasm instruction set, with the translation in all other platforms

Can you give an example?

On first reading it looks like you describe an HLL.

it looks lika hll, but with asm syntax and then, cpu mechanism is not hiden.

mov eax,1 for example is movlw 1 if translated from X86 to pic.
and movlw 1 becomes mov eax,1 if pic to x86, or any other register set to be the W register. eax is by default the accumulator in x86.

mov regA,regB becomes movf regB,W / movf regA,W with X86 to pic, but of course, the conditionnal assembly can be used to ignore the second instruction if the default accumulator is regA.

and so on with every instructions .

the work is very huge to make a UASM instruction set, and UASM translations macros, but nothing seems to be impossible.

Well, my 2 cents…

In fact, if you think about it, it’s a matter of choosing between limited instruction set and low performance.

If we start with, say, a set of atomic operations, we lose lots of useful instructions that don’t fall into this category, especially for CISC architectures.

If we start adding some equivalents for those, we’ll have to implement them with code pieces on RISC architectures. Which means a tiny instruction that looks like something lightweight (and might be for some CISC architecture) will eventually become slow on some other hardware.

Which basically is what we know as HLL, except that they use a set of higher-level primitives which at least gives their compilers the opportunity to optimize not only separate constructs but their combinations as well. Might not be the case if we treat the hypothetic UASM as… um… assembler.

Well, obviously, we could balance the set of “universal instructions” to optimize trade-offs for particular tasks. But would it really be universal then?

modern hardware has deep pipeline and cache
we need HLL to convert our branches into bitwise ops
to batch process pre sorted chunks
either we relearn how to program or use HLL
even modern gcc can optimize switch cases out if used with constant value
i often do think of the perfect language, c is best i have found so far, but it has its quirks too

In x86 we can do this: But it is only possible on ARM64 with multiple instructions, and impossible to do that on PIC.

In ARM32 we can do this: In x86 you need to have spare registers available to do some intermediate operations. Do you keep those registers as spares "just in case"? If so then you lose a lot of opportunities for making good code.

Until one day you find out type sizes are implementation-defined and may not even be multiples of 8 bits, and radix for floating-point values might some day become 3 or 4 (since it’s defined by the implementation as a symbolic constant in one of the standard h-files), so writing cross-platform code in fair manner becomes a nightmare?

As you might guess, I definitely double this:

i don't see any limitation to a conditional macro system, else than the huge amount of work for every usecase.

but yes, C is for the moment one of the best ways to make universal code.

here, it's asm related topic, meaning universal assembly would be a lot of asm like instructions set.

the only part where it would be fine to don't write asm mnemonics is for math expressions. with any operand to be compatible with asm operands.

then, eax = eax*[table+ebx*4]/ratio would be possible and be translatable to instructions.

maybe the problem here is not really universal asm, but only expression translation to let the programmer write expressions and don't deal with the uber complex job of asm formulaes composition....

I think assembly language/syntax isn't suited to be universal. That isn't really it's purpose.

Use assembly to exploit the CPU and make good code. Use HLL to make average code that might run on different architectures.

I've given some thought to the subject of a universal assembly-language, and I have thought up a good name for it: the Hugh-niversal assembler!

My HJA430 assembler (https://board.flatassembler.net/topic.php?t=21841) is a step in this direction. The idea is to assume the MSP430 as a basic 16-bit processor with a reasonable level of features. HJA430 can be rewritten to generate code for a different 16-bit processor.

The PIC24 is more powerful than the MSP430, so if you generate PIC24 machine-code, you are not taking full advantage of the PIC24. To some extent, this can be worked around by using a code-library that contains functions such as multiplication and division, and having the functions in the code-library written using the full instruction-set of the target processor (the PIC24 in this case).

The MC6812 has fewer registers than the MSP430, so pseudo-registers in memory will need to be used to correspond to all of the MSP430 registers. The MC6812 has multiplication though, that the MSP430 doesn't, so this would be taken care of in the code-library.

What is the point of this???
The point is to write a Forth system using the Hugh-niversal assembler. This Forth system can be ported to a new processor by writing a new version of the assembler that generates machine-code for the new processor.
The purpose of this is to allow the Forth system to begin running on the new processor without needing to be rewritten. You only need to rebuild it using the new version of the assembler, and it should then run without any modification of the Forth system's source-code.
This is called: "information hiding"
All of the "carnal knowledge" regarding the new processor is inside of the assembler source-code. You don't have this carnal knowledge scattered all over the source-code of the Forth system, so you don't have to make modifications all over the Forth system's source-code which would be very error prone. Your Forth system can be quite complicated, doing analytic compilation to optimize the code by holding values in registers. All of this complicated code will work on any new processor without needing any modification that would risk breaking already tested and working code.

The Forth system's source-code is significantly more complicated than the assembler's source-code. The HJA430 source-code is a pretty small file and it is pretty straight-forward, so it should not take long to rewrite this to generate machine-code for a new processor. As an experiment, I intend to rewrite HJA430 to generate machine-code for the PIC24 which is the only other 16-bit processor still in common use (the MC6812 is pretty much obsolete).

I have described this idea in the past, and people typically don't understand what I'm talking about. They think that I mean that the PIC24 will emulate the MSP430 machine-code with a VM. This is totally failing to understand! The machine-code for the Forth system will not be ported to run on the new processor --- the source-code for the Forth system will be reassembled using a new version of HJA430 to generate machine-code for the new processor.