flat assembler
Message board for the users of flat assembler.

Index > Projects and Ideas > Portable assembly code?(between archs)

Goto page Previous  1, 2, 3, 4  Next
Author
Thread Post new topic Reply to topic
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
If you want a HLL that does everything, try C++ or Perl or ..., but it's probably better and more realistic to only target a certain subset of functionality (e.g. text, files, etc. or gfx, sounds, etc). I think Forth would be a good lang to try since it's pretty small and portable.

Of course, there are many, MANY languages already, so reinventing the wheel may not be necessary (but, by all means, go ahead: I wouldn't want to discourage the next Larry Wall or Matz or Ralph Griswold, etc.)
Post 29 Mar 2007, 01:32
View user's profile Send private message Visit poster's website Reply with quote
ssp



Joined: 05 Mar 2007
Posts: 38
Location: India
ssp
hckr83 I too wish that every microprocessor in the world would
understand the intel assembly. Wow!
Eg. it is certainly possible to use 8086 in small portable devices.
And 80386+ for low cost home PCs.
And IA64 beasts for high-end servers.

But every one should have used intel syntax and every microprocessor
should be opcode compatble with intel opcodes.

And the intel opcodes should no longer belong to intel itself but
should be made into an open architechture, governed and
standardised by indipendent authorities like IEEE, ISO etc.
Post 20 Jun 2007, 02:57
View user's profile Send private message Yahoo Messenger Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
I'm for intel syntax everywhere, since it's the most logical syntax for me.

But intel opcodes? No. There are more comfortable instruction sets available like instruction dest, op1, op2, where you aren't bound to fixed destination registers, where you have plenty registers to work with, etc.

And if you look at the actual opcode encodings for x86, it's a goddamn mess. It really shows that x86 is ooooold, and was extended in an ugly patchwork style - especially for SSE instructions.

Yeah, it works, but I'm still convinced that we'd get more bang from our GigaHertz if we did some architectural changes.
Post 20 Jun 2007, 12:02
View user's profile Send private message Visit poster's website Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
Too bad we can't make our own CPU...
Post 20 Jun 2007, 19:37
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Maverick in another thread which I can't remember now wrote:
You can, buy a FPGA and learn Verilog
Post 20 Jun 2007, 19:43
View user's profile Send private message Reply with quote
courage



Joined: 22 Jun 2007
Posts: 4
courage
Hello All people:

First, I am a newbie for assembler programming,
and don't have much programming experience.
And English is not my mother language,
so please forgive my bad grammar.

In my immature opinion, to write a portable assembler,
not fully "write once, compile every where",
just let "write once, modify a few codes, then compile"(like using C),
We can do that:

First, we have to consider all the architecture as a stack machine,
thus we can avoid to use register and just use variables and stack.

Second, we should have a compiler to optimize stack machine codes to
register architecture codes.

To do this, we can refer to some stack machine implements
like "Forth to native" or "JIT of Java Virtual Machine".

But Forth or JVM are high level programming language orient,
we can do an assembler language orient compiler,
and integrate the compiler into FASM,
then we can write original assembler and use "port mode" to
write portable stack machine codes.

I think stack machine code is so low level enough
to be optimized easily more than high level language like C.

If I have some wrong concepts or grammar, please tell me. Thanks.
Post 22 Jun 2007, 08:58
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
courage: if you do something like that, what's the advantage of coding in pseudo-assembly as opposed to coding it in C and enjoying 20+ years of compiler improvements?

It's easier to write an optimizer for a (relatively) high-level language as C than for a lower-level stack machine, since you have more leway to apply optimizations. If you're coding in something as low-level as assembly, you'll want to be doing optimizations yourself, and that's somewhat hard to do with pseudo-asm.

_________________
Image - carpe noctem
Post 22 Jun 2007, 11:26
View user's profile Send private message Visit poster's website Reply with quote
courage



Joined: 22 Jun 2007
Posts: 4
courage
f0dder wrote:
courage: if you do something like that, what's the advantage of coding in pseudo-assembly as opposed to coding it in C and enjoying 20+ years of compiler improvements?

Hi f0dder:

I am not sure, but I think you are right.
(I have to learn more about optimization to be sure.)

But I am a little confused.
If we don't have any opportunity to win C without asm in performance,
what does the C-- project do?

I mean that C-- code looks like C code but just uses "goto"
to instead of "for" and "while" loop instructions,
and it can return multi-values(it can be done with struct in C) and
directly goto function address(it can be done with inline asm in C).

If we just use "goto" instead of "for" and "while",
than C compiler can give us the best and closed to human made asm codes?

If C-- couldn't defeat C in performance, what the meaning does C-- exist?
A C with GC and exception without loop instructions?

Quote:
It's easier to write an optimizer for a (relatively) high-level language as C than for a lower-level stack machine, since you have more leway to apply optimizations.

would you please give me more information about this? Thanks.
(Of course, My imagine about the stack machine/pseudo-asm is like jasmin, not like C-- or Forth.)


Last edited by courage on 22 Jun 2007, 14:21; edited 2 times in total
Post 22 Jun 2007, 13:25
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
As I see it, C-- is just a "lightweight C" without much optimization. I don't see much reason to use such a project - either I use a fullblown optimizing C++ compiler, or I use assembly.

courage wrote:

f0dder wrote:

It's easier to write an optimizer for a (relatively) high-level language as C than for a lower-level stack machine, since you have more leway to apply optimizations.

would you please give me more information about this? Thanks.
(Of course, My imagine about the stack machine/pseudo-asm is like jasmin, not C--.)

A line of source code in a high-level languageconveys more information than a lower-level language, by definition. Ie, it's pretty clear what "for" and "while" are intended to do. In assembly, there's a variety of ways to construct a loop, and it's not very easy for an "optimizing assembler" to detect 100% what is a loop and what isn't.

And that was just a simple example. I'd say, and do keep in mind I haven't written a compiler yet Smile, that it's easier to do subexpression elimination, code folding, etc. in a HLL than with something as low-level as assembly.

Imho the usefulness of assembly isn't that it's low-level, but that you code in the machine's native language, WYCIWYG style, with the ability to use the full instruction set, and hand-tune your code. A "portable assembler" would just be a low-level (which is imho tedious) language without the advantages of assembly.
Post 22 Jun 2007, 13:38
View user's profile Send private message Visit poster's website Reply with quote
courage



Joined: 22 Jun 2007
Posts: 4
courage
f0dder, thanks for making me to be clear with "portable asm". Smile
Post 22 Jun 2007, 14:20
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Well, that's just my opinion, everybody's entitled to one Smile
Post 22 Jun 2007, 14:25
View user's profile Send private message Visit poster's website Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
The worst part about this is that it'd be tedious enough trying to write on one platform. Once you have a converter for one platform to use with another platform, try getting the converter to also be cross-compatable with a 3rd platform.

Quote:
There are more comfortable instruction sets available like instruction dest, op1, op2


Despite how much i've hated intel's design at first, i eventually came to really like it, but when i use instructions that i don't use alot that contain a slightly different from the other instructions (div and mul are the big ones) i do wish those were changed a bit.

Quote:
where you aren't bound to fixed destination registers


What do you mean? They have registers out there that can be addressed like memory?

Quote:
where you have plenty registers to work with


Yea, that would be nice. The intel machine has plenty of registers, but i've found you really can't use them much outside their standard purpose.

Quote:
And if you look at the actual opcode encodings for x86, it's a goddamn mess. It really shows that x86 is ooooold, and was extended in an ugly patchwork style - especially for SSE instructions.


Which means it would be nice if intel came out with a processor from scratch intended for use with handhelds or game consoles. I've noticed intel isn't overly big on giving you lots of "fast memory" which is all over the place. I looked at the hardware map of the DS once and it was a bit disorienting. I know it was for 2 processors, but jeeze.
Post 23 Jun 2007, 10:15
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
kohlrak wrote:

f0dder wrote:

where you aren't bound to fixed destination registers

What do you mean? They have registers out there that can be addressed like memory?

No, I meant in the "mul" and "div" sense... as well as ordinary things like "add" and "sub" not specifying a destination reg, but using op1 as dst.

kohlrak wrote:

Yea, that would be nice. The intel machine has plenty of registers, but i've found you really can't use them much outside their standard purpose.

IMHO they don't have plenty of registers. Something like 16 (truly!) general-purpose registers would be fine. On x86, only EAX,EBX,ECX,EDX are truly general (in the sense they can also be addressed in the 16- and 8-bit parts), ESI, EDI and EBP are general as well but can't be 8-bit addressed. EBP is often used for compilers, but at least it's "free-use" which ESP isn't 100%.

On top of those restrictions are the various limits imposed by various instructions... but at least in 32-bit flat memory model operating systems you don't have to worry about implicit segment/selectors and shit like that.

Of course, internally, most x86 CPUs have had a shitload of registers, made available as the x86 register set through "register renaming"... and there's some pretty hot execution units as well, but we're being held back by the x86 frontend and stupid legacy.

kohlrak wrote:

Which means it would be nice if intel came out with a processor from scratch intended for use with handhelds or game consoles.

The last point in time where this was a real possibility was with the 80386, but they blew it. They tried again with the IA-64 architecture, but they aimed it solely at the server and high-end-workstation market, which meant AMD had a chance to ruin any hope of every leaving x86 by introducing AMD64/x86-64/ia32e/EM64t (call it what you want, I prefer x86-64).

kohlrak wrote:

I've noticed intel isn't overly big on giving you lots of "fast memory" which is all over the place.

*shrug*, the core2duo has 4meg cache, the quadro has 8meg. That's a lot of really high-speed memory, transistor-wise. And DDR2 isn't half bad either Smile
Post 24 Jun 2007, 16:24
View user's profile Send private message Visit poster's website Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
Quote:
No, I meant in the "mul" and "div" sense... as well as ordinary things like "add" and "sub" not specifying a destination reg, but using op1 as dst.


Now THAT would be nice. I've never really gotten used to mul and div...

Quote:
IMHO they don't have plenty of registers. Something like 16 (truly!) general-purpose registers would be fine. On x86, only EAX,EBX,ECX,EDX are truly general (in the sense they can also be addressed in the 16- and 8-bit parts), ESI, EDI and EBP are general as well but can't be 8-bit addressed. EBP is often used for compilers, but at least it's "free-use" which ESP isn't 100%.


Which is plenty, the problem is as you said though. We can't use them.

Quote:
On top of those restrictions are the various limits imposed by various instructions... but at least in 32-bit flat memory model operating systems you don't have to worry about implicit segment/selectors and shit like that.


AMEN!

Quote:
*shrug*, the core2duo has 4meg cache, the quadro has 8meg. That's a lot of really high-speed memory, transistor-wise. And DDR2 isn't half bad either


I'm actually referancing the system with dual arms. I'm not neccesarily fond of a large collection of memory where some of it can be shared, some of it can't. That kind of thing. I like intel. It needs to boot out all the junk and start over, do something about mul and div, and give us a few more registers to work with that we're allowed to use. I like the simplicity of intel, but i don't like the patchwork.
Post 24 Jun 2007, 18:11
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
courage



Joined: 22 Jun 2007
Posts: 4
courage
Hello all people:

I remembered one thing that I had read a book about
the management in the team work in early Microsoft.

The author is the manager of EXCEL team
and he said they used a cross-platform(or portable?) version of MASM to
port EXCEL 2.0 (maybe higher) to Macintosh.

If they were not rewrote all the codes to prot EXCEL to Macintosh,
I am very very curious about how they did it?(or what the MASM looks like?)


Last edited by courage on 27 Jun 2007, 01:20; edited 1 time in total
Post 26 Jun 2007, 13:50
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
I remember hearing something about the early excel (and other office apps?) not actually being written in x86 assembly, but some "pcode" thing. Porting the execution environment for such a solution is probably not as big deal as porting an entire set of applications.

But I could of course remember wrong Smile
Post 26 Jun 2007, 14:06
View user's profile Send private message Visit poster's website Reply with quote
m



Joined: 28 Dec 2006
Posts: 304
Location: in
m
It would have been better, if intel processors understood the C
language.

Better yet, if they understood C++.

_________________
Attitude!
Post 10 Jul 2007, 04:46
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
That'd be lame.
Post 10 Jul 2007, 10:52
View user's profile Send private message Visit poster's website Reply with quote
m



Joined: 28 Dec 2006
Posts: 304
Location: in
m
f0dder wrote:
That'd be lame.

Is that directed to me?

Code:
If yes
        Why a processor understanding (natively) a HLL is a bad-bad idea?
End If
    

_________________
Attitude!
Post 11 Jul 2007, 10:32
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
It would be an overly complex architecture with no real gains...
Post 11 Jul 2007, 10:59
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3, 4  Next

< 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-2019, Tomasz Grysztar.

Powered by rwasa.