flat assembler
Message board for the users of flat assembler.

Index > Non-x86 architectures > UASM, Universal ASseMbler.

Author
Thread Post new topic Reply to topic
edfed



Joined: 20 Feb 2006
Posts: 4252
Location: Now
edfed
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?
Post 10 Dec 2020, 11:15
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17999
Location: In your JS exploiting you and your system
revolution
edfed wrote:
... atomic operations, commons to every cpus.
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.
Post 10 Dec 2020, 11:40
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4252
Location: Now
edfed
revolution wrote:
edfed wrote:
... atomic operations, commons to every cpus.
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
Post 10 Dec 2020, 12:34
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17999
Location: In your JS exploiting you and your system
revolution
Can you give an example?

On first reading it looks like you describe an HLL.
Post 10 Dec 2020, 12:36
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4252
Location: Now
edfed
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.
Post 10 Dec 2020, 13:36
View user's profile Send private message Visit poster's website Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 914
Location: Belarus
DimonSoft
edfed wrote:
revolution wrote:
edfed wrote:
... atomic operations, commons to every cpus.
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

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?
Post 10 Dec 2020, 18:53
View user's profile Send private message Visit poster's website Reply with quote
bitshifter



Joined: 04 Dec 2007
Posts: 786
Location: Massachusetts, USA
bitshifter
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

_________________
Coding a 3D game engine with fasm is like trying to eat an elephant,
you just have to keep focused and take it one 'byte' at a time.
Post 10 Dec 2020, 20:00
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17999
Location: In your JS exploiting you and your system
revolution
edfed wrote:
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.
In x86 we can do this:
Code:
mov reg, 0x1234567890abcdef    
But it is only possible on ARM64 with multiple instructions, and impossible to do that on PIC.

In ARM32 we can do this:
Code:
add r0, r1, r2, lsr r3    
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.
Post 10 Dec 2020, 22:39
View user's profile Send private message Visit poster's website Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 914
Location: Belarus
DimonSoft
bitshifter wrote:
c is best i have found so far

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:
bitshifter wrote:
but it has its quirks too
Post 10 Dec 2020, 22:53
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4252
Location: Now
edfed
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....
Post 10 Dec 2020, 23:45
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17999
Location: In your JS exploiting you and your system
revolution
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.
Post 10 Dec 2020, 23:50
View user's profile Send private message Visit poster's website Reply with quote
Hugh-Aguilar



Joined: 26 May 2020
Posts: 36
Hugh-Aguilar
DimonSoft wrote:

Until one day you find out type sizes are implementation-defined and may not even be multiples of 8 bits...

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.

_________________
When all else fails, write the source.
Post 09 Apr 2021, 07:06
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.