Index
> Projects and Ideas > Portable assembly code?(between archs)Goto page Previous 1, 2, 3, 4 Next |
| Author |
|
|
rugxulo 29 Mar 2007, 01:32
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.) |
|||
29 Mar 2007, 01:32 |
|
|
f0dder 20 Jun 2007, 12:02
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. |
|||
|
20 Jun 2007, 12:02 |
|
|
kohlrak 20 Jun 2007, 19:37
Too bad we can't make our own CPU...
|
|||
|
20 Jun 2007, 19:37 |
|
|
LocoDelAssembly 20 Jun 2007, 19:43
Maverick in another thread which I can't remember now wrote: You can, buy a FPGA and learn Verilog |
|||
|
20 Jun 2007, 19:43 |
|
|
courage 22 Jun 2007, 08:58
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. |
|||
|
22 Jun 2007, 08:58 |
|
|
f0dder 22 Jun 2007, 11:26
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. _________________  - carpe noctem |
|||
|
22 Jun 2007, 11:26 |
|
|
courage 22 Jun 2007, 13:25
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 |
|||
|
22 Jun 2007, 13:25 |
|
|
f0dder 22 Jun 2007, 13:38
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:
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  , 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. |
|||
|
22 Jun 2007, 13:38 |
|
|
courage 22 Jun 2007, 14:20
f0dder, thanks for making me to be clear with "portable asm".
|
|||
|
22 Jun 2007, 14:20 |
|
|
f0dder 22 Jun 2007, 14:25
Well, that's just my opinion, everybody's entitled to one
|
|||
|
22 Jun 2007, 14:25 |
|
|
kohlrak 23 Jun 2007, 10:15
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. |
|||
|
23 Jun 2007, 10:15 |
|
|
f0dder 24 Jun 2007, 16:24
kohlrak wrote:
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:
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:
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:
*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 |
|||
|
24 Jun 2007, 16:24 |
|
|
kohlrak 24 Jun 2007, 18:11
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. |
|||
|
24 Jun 2007, 18:11 |
|
|
courage 26 Jun 2007, 13:50
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 |
|||
|
26 Jun 2007, 13:50 |
|
|
f0dder 26 Jun 2007, 14:06
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 |
|||
|
26 Jun 2007, 14:06 |
|
|
m 10 Jul 2007, 04:46
It would have been better, if intel processors understood the C
language. Better yet, if they understood C++. _________________ Attitude! |
|||
|
10 Jul 2007, 04:46 |
|
|
f0dder 10 Jul 2007, 10:52
That'd be lame.
|
|||
|
10 Jul 2007, 10:52 |
|
|
m 11 Jul 2007, 10:32
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! |
|||
|
11 Jul 2007, 10:32 |
|
|
f0dder 11 Jul 2007, 10:59
It would be an overly complex architecture with no real gains...
|
|||
|
11 Jul 2007, 10:59 |
|
| Goto page Previous 1, 2, 3, 4 Next < Last Thread | Next Thread > |
Forum Rules:
|