Slashdot Mirror
Analysis of Amiga Virtual Processor ASM
An anonymous reader sent us an analysis
of the new Amiga Virtual Processor assembly Language -- unlimited registers, register naming, high-level looping constructs, a tool-based architecture, and object-based assembly programming,
complete with some cool examples.
First of all, the article contains an error (And it wasn't written by some anonymous person, as someone claimed, but by Daniel Robbins, President/CEO of Gentoo Technologies, Inc.).. The VP code isn't just translated the first time it's run, but at load time. Why?! I hear you ask.. Simple, the VP binaries are smaller than the native and the little overhead from tranlating is won back due to shorted load time. Compiling to native once would also double the diskspace required, as you would have to store both VP and x86 (for example) versions! And in a multiprocessor system, you don't know which processor that will execute each tool (Applications for AmigaDE consists of numerous tools (Small VP code smippets) that are loaded and translated when needed, thus reducing startup time and memory consumption furter) and because the processors might have different architectures (x86, PPC...) you would need one native version for each different processor in your computer.
Regarding the speed issue.. When running hosted (Ontop windos, Linux or other) you'll never achieve full speed, but AmigaDE's also able to run natively, accessing the hardware direclty (Not the software, as it's hardware independant, but the kernel). And in that case I believe it will easily outperform windows (not very hard) and atleast equal other OSes running natively on the same hardware.
I own the early SDK released (Meant to be used for drivers development, so ppl who didn't understand that always complain about it being so unfinished) and with every update there's a noticable performance boost. It's definitely too early to tell what the finished AmigaDE's going to look and feel like, but even the SDK feels snappy and quite powerful (Though mine is hosted on Linux) so personally I think they might have a chance.
Quake{1|2}'s software renderer used a pipelined FDIV for texturing that was critical for performance. Later iterations of the Quake2 engine used MMX to do single-pass 16-bit RGB lightmap blending, which also was helpful for speed.
Suffice to say the hardware renderers don't use any of this. I think there is a small bit of asm in Q3 for the VM stuff (like 5 lines).
m.
Loki Software, Inc.
"Sebastian you're in a mess. They called you King of all the Hipsters, is it true or are you still the Queen?" -- B
You seem to be missing the point. The SDK is released with compilers for C/C++. It does come with a development tools for Java. Python has been ported by third parties. REBOL and Arexx is already available for it.
;) It's an old buzzword just waiting to be reborn.
There is no do-it-all-in-assembly about the Amiga SDK.
On the other hand, if you decide to write assembly, it's just not painful anymore. As a matter of fact, I prefer programming VP over straight C; VP has more features, and can be programmed "as clean". The beauty of it all is that you have full access to the C-library and major parts of POSIX, in addition to a set of system specific functions.
If anybody wants more examples of VP code as illustration, I'll be happy to provide them.
On the other hand, while VP is easy to write code for, please don't forget that most people will never (want to/have to) write code in it directly.
Also, you were dissin' the opcodes; most of what you see isn't opcodes but macros. I'm sure a list of actual opcodes can be produced as a basis for futher discussion.
BTW, yesternight I sat down to write a small server application that spawns off child processes when connected to. 20 hours later it's a 1088 byte executable. I had some problems along the way, so I decided to also implement it in C++; the VP-"binary" turned out to be about 3520 bytes. (And yes, this executable also reads a configuration.) Just a small sidenote to illustrate how lean the system is, and to urge all of you to start writing Internet apps in assembly.
...but many programs compiled for the Amiga/Tao platform used gcc. How do you think all the unix utilities exsist for amiga?
Also I have heard wind that metroworx is doing a port of their compiler to Tao.
Think most people want to program in anything called an assembly language? not I.
--
-- Virtual Windows Project
When you code in VP assembly, you let the assembler and dynamic translator worry about all those registers
Is't that what a compiler and linker do? Why would you use defines and instead of programming in C and just delaring a variable? Why not just write a nice optimizing compiler back-end to do this? Is it just me or does this sound a lot like re-inventing the Wheel?
flounder
Sorry for all the rhetorical questions, but as Steven Wright always says "What if there were no rehtorical questions?"
I don't like
This article doesn't really convey the point of the Tao Group's technology. Sure its a nifty assembler, but programmers middle aged and above will remember that assemblers used to be very much like this back when humans used them. Thats not new. (Dang whippernappers always thinking they're inventing repiration.)
:-)
The point behind the Tao stuff is that all of your code is built to the virtual assembly language and shipped as the virtual machine code. It is translated to local machine code as needed on the target system (and cached as appropriate for that system, eg. once forver to disk for desktop PCs).
This means one version of the application that runs on any (supported) target processor. It also means your final executable code is optimized for your particular processor, say K7 instead of just generic IA32 instruction set.
Tao has been add this since at least 1995, maybe earlier. They have good technology. Maybe its even useful.
I've been thinking about portable assembly for a while now. Sometimes you want to get as low level as you can, but also want to be portable. It would at least be an interesting academic project (somebody must've done this already) to attempt to abstract most essential assembly instructions to a virtual set, which can then be translated to a closely matching native set, at compile-time. So you get more or less the strength of assembly programming, with the nice feature of portability and common syntax and operations, etc.
The Crusoe chip, and the Java VM, are taking us more and more towards dynamic compilation/execution environments, already. I think some type of portable assembly would be cool. (I guess you could write raw bytecode, but you still wouldn't be able to compile that natively...perhaps somebody just needs to write a bytecode->native compiler (I think Symantec and several others already have))
It's 10 PM. Do you know if you're un-American?
Compact code...
Discipline...
Optimization...
Amiga design made all that pseudo-intellectual masturbation unnecessary. It was an environment. The reason it looks like C is because the hardware itself was structured.
Loading a program literally involved acquiring a pointer to where it was loaded.
Course I know of a system that's going to use Forth. For those who have no idea, FORTH is easier than HTML to program. And it's extendable without even making one flinch at the task.
You can extend Forth directly in Forth code.
The message on the other side of this sig is false.
seems like everything is heading for high level... That just doesn't even seem like ASM. I mean, isn't that what we want? Ease of coding, fast execution, and small executable size?
will the SDK cause the executable to be slower/larger b/c of overhead? They really didn't go into that kinda stuff in the article.
Of course, the new Amiga can't be any worse than the old ones; those geezers ran on a 68040!
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
I think the VM is an idea whose time is finally coming. Processor speed is coming up fast enough and for common applications (primarily in the consumer market) that even with the performance hit by running the VM with either JIT compilation or code morphing (or even both) still leaves you with good performance for common applications. And the benefit you get from compatibility issues really makes life pleasant with a well designed VM.
Honestly, as people keep wanting to run x86 code and the hardware people are having fits from trying to boost even more performance trying to run x86 code directly, you're just going to see the total surrender and the declaring of the x86 instruction set as a VM spec not unlike the Amiga VM spec, only not quite as well thought out.
From there its a shorter leap to supporting multiple instruction sets and the emulation of legacy systems really takes off. Combine that with something like VMWare and you've got a system that can boot up virtual machines of all sorts of hardware configurations to run legacy software. And something like the Amiga VM with an artificially designed instruction set that would be impossible to do in hardware suddenly looks attractive from a development standpoint.
To answer your post, you could combine the VM with Linux. At that point you can create Linux binaries that will run on any processor type. Companies that don't want to release their source code (and I am quite understanding of companies not wishing to do that) can release a binary that will run across all processor lines.
I did think it was cheesy to use the Amiga name though. I tend to agree with others the name should have been allowed to go into honorable retirement.
Troll? Who modded me troll?
It's a joke, god dammit.
Fuck. We need a class called Moderation for Dummies.
Free Point on the exam: this post is an example of flamebait.
If tits were wings it'd be flying around.
Ever look at the size of the average C compiler? The executable is huge, it involves all sorts of passes from external programs, and runs like a dog. Writing a straightforward and simple C compiler, like Small C (which had the source code published in a thin book over fifteen years ago), isn't too bad. But C hasn't scaled well. It has gotten out of control.
The VP was designed to be simple to translate to real machine code, and have good speed of execution. It's a definite balance. Remember, VP code is translated to machine code on the *fly*. You wouldn't want to have to run a C compiler every time you started an application, would you?
Here's another way of thinking about it. In the mid 1980s, the average PC C compiler fit on a 360K floppy disc and worked in 640K memory. I remember Amiga C compilers than ran fine in 512K on the original 7+ MHz processor. But now you can't get enough processor power to compile. gcc and Visual C++ and CodeWarrior just eat up the cycles like there's no tomorrow. Then there are compilers like Borland's Object Pascal that are hitting 1,000,000 lines per minute on old hardware. Going with the VP over C was a good choice. It gets away from a lot of C baggage that we like to pretend doesn't exist.
If I understand it right, it's a good idea: optimal loop unrolling is performed in a different manner on different platform.
This way, you have the actual loop in the bytecode, which can be unrolled and translated very efficiently for the specific architecture.
While I believe that nothing could beat a human being when it come to coding to one specific architecture, I believe optimizers can do a damn good job when it comes to support several architectures. Example?
Take a simple loop in ANSI C, compile with the optimizer. Then unroll by hand the very same loop (using something like the Duff's Device). Compare the results. On a single architecture a human can take in account the CPU characteristics, and do the best optimization, but if you have to support several architectures, unrolling by hand could result in better bytecode for some, but worse bytecode for all the others.
So, having an intermediate language (I wouldn't call it "assembly") designed with optimizers in mind should be a Good Thing(TM).
If I remember correctly, one of the mistakes in designing the JVM is that a great deal of information is left out when compiling to bytecode, so JIT compilers can only do a less-than-optimal job (and you pay it in speed). I don't know if the Amiga virtual machine is better at this, but I bet it is.
Second, their would have to be a service ala Tivo that would provide the TV guide features. They could recoup any cost the Hard Drive would add to the set top box. Also, by the time they'd have it developed, that 40 gig might only be around 100 bucks.
Um, have you not heard that emulation is legal? Remember Connectix won their case with their emulator, and I see Bleem on the shelf at Best Buy. I don't think it would be illegal to emulate a PSX or a PS/2. Also, they could do Dreamcast fairly cheap from the sounds of Sega's problems. Heck the PS/2 might be all of these soon (with initial added cost for hardware upgrades).
The impossible is not always impossible when you think how much time they'd have to take to develop this. People thought the initial costs of the PS/2 were prohibative. But Sony still made those. (I know, Sony is big japanese corporation and more capable then Amiga. Some thing was true about IBM (except the japanese part) when the Amiga first came out. Look what was better then.....).
Gorkman
"Just think: unlimited registers, register naming, high-level looping constructs, a tool-based architecture, and object-based assembly programming. Amazing!"
Well. I do have a weird sense of humor (I, for instance, wrote the first[?] self-replicating INTERCAL program), but this seems like a practical joke.
'ifnoterrno' just sounds like a terrible opcode for me. 'defendnz' too.
and in, 'qcall lib/argcargv,(-:p72,i20)' you can see the smiley...
Unfortunately, it looks like those people are dead serious.
I thought only the [original incarnation of the] berlin project had this over-the-top NIH syndrom, do-all-in-assembly. Those guys push it even further. They also want to do the assembly themselves. A pity, because the graph library looks nice. They should release this with high-levels bindings (ie: with squeak, python or tom. As now, it looks like a False or Befunge interface. See http://www.catseye.mb.ca/esoteric/index.html for more info)
Cheers,
--fred
1 reply beneath your current threshold.
We're used to dissing VMs because, for the most part, the intention behind them has been portability above all, write once - run anywhere, rather than to maximise efficiency on any platform. This goes from everything from the UCSD p-System to Java, all of which are normally supplied in some interpreted form by default, with JIT compilation being seen as a handy way of increasing efficiency for the particular model involved.
My understanding of what Amiga are trying to do is of a more impressive intention. To understand this, you have to look at how modern compilers work.
Right now, if I compile a C program, it has to be for a particular hardware configuration. By this, I don't mean from a portability standpoint - if I compile for the i386, then my program will work on the very latest Pentium without modification. But it wont run as efficiently as if it were compiled for the latest Pentium. And if I compile it for the latest Pentium, then when the IA-64 comes out, it wont run efficiently on that. Hell, it wont even run efficiently on the Pentium 5 or 6.
The solution is don't compile for a processor. Compile for a VM which is designed, as much as possible, to abstract the high level constructs within a program to a degree that a JIT compiler can easily optimise the program as much as possible, to a point that the JIT compiled code will run just as fast, at minimum, as it would have ran if compiled for the running platform to begin with.
So if you're running something on an i386, it will run at the fastest speed it could ever have run on an i386. If you run it on a Pentium III, it will run making use of everything from MMX to the "standard" enhancements of the P3 to the configuration of instructions where doing something one way on one CPU might run with opposite efficiency to another way when run on a different CPU.
People posting here seem to be either of the opinion that Amiga are encouraging people to write in "their" assembler - they're not, the intention is to get compilers to translate to "their" assembler. And then a user can chose a VM engine for their platform.
I think the idea is pretty cool. I'm contemplated the consequences of doing this for a long time, and I'm delighted someone has gone out and had the balls to do it: even more so, that they're associating the Amiga name with such a project, as an Amiga died-hard myself. [died-hard = die hard who sold out]
--
You are not alone. This is not normal. None of this is normal.
There is no <pre> anymore because some fsckwads abused it and posted really, really, really, wide sentences. Which, of course, allowed everyone else's non-preformatted posts to be really, really, really wide.
Horizontal scrolling sucks.
"Free your mind and your ass will follow"
Think most people want to program in anything called an assembly language? not I.
But a lot of that comes from brainwashing by college professors and the like. I remember when a newbie co-worker found out I had written a smallish program entirely in assembly language, he couldn't believe it. He had heard "you cannot write code in assembly because it is impossibly difficult" from too many sources.
Assembly is trivial and predictable. There are good reasons to work with at, and there are good reasons not to. Two of the reasons not to are (1) portability, and (2) processors are changing are changing much too quickly. Both of those go away in this case. Something to note about this so-called VP assembly is that it is designed to be simple for the programmer. That makes it very different than writing code for messed-up processors like those in the x86 family, or where the designers deliberately do messy stuff because they don't care how it looks on the back end (e.g. Itanium).
Amiga has always been ahead of the curve. I remember back in 89 or so having to write a serial-based communications program that talked between a VAX (running VMS) and an Amiga.
Thought the VMS part would be easy and the Amiga a pain of stupid little PC-like low-level calls.
Well, it was the opposite. VMS required me to learn QIO calls that had 13 parameters each, and took about 200 lines of code.
The Amiga side was about 50 lines of code and was basically a simple wrapper around the firmware routines that already did everything I wanted. They had tripple-indirect semephores in firmware on a dinky little game platform in the 80s. I hear the UNIX port was nice as most of the low-level including task management, VM (much more than just page tables), and many other features were all in hardware.
Nice box, hope they do as well with the new one!
The Amiga VP seems to be equivalent to a Java VM. So why should I prefer to code in Amiga VP assembly code rather than in Java?
I'm a leaf on the wind. Watch how I soar.
When a programmer knows everything about the platform he's programming for, then he(or she, of course) can write faster programs than any "optimizing compiler." The only reasons it isn't done more nowadays are twofold:
a) Optimizing compilers are actually quite good at what they do, even if a human could do better.
b) It's nearly impossible in this day and age to know everything about the platform you're programming for.
And when I say "everything", I *mean* it. You need to know trace lengths, latencies, exact timings on *each instruction* that's run.
Ever wonder why most Palm apps are so fast, considering they're on a lowly processor? Well, lots of people that write intense Palm apps use assembly - and the hardware is not only very standard, it's also simpler than your average 386/SX.
Dave
'Round the firewall,
Out the modem,
Through the router,
Down the wire,
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
From what i understand from previous articles and the interviews i've read, is that the Amiga Binary is compiled to native code when you run it, and then it runs native. This sort of thing hasn't worked too well in the past (for instance the NT for the Alpha was supposed to have something to do this for intel assembly...) but I'm confident that this will work well and fast because instead of being used to deal with some really hairy legacy processor (like most of these rigs are supposed to do...) it's compiling from a source that was designed from the ground up to be translatable.
I'm psyched. Next paycheck, i want to buy the SDK =:-)
---
Play Six Pack Man. I
> C is becoming a bloated mess of a language and shouldn't be used unless totally neccessary
I'd say nope. C is not bloated. It is the libraries that are bloated. C almost didn't change over the years.
C++ is bloated (well, have always been, but have seen its bloat increased a lot between 89 and 95) because they added ton of stuff to the language.
So, sorry, no. C is _NOT_ bloated. libc, Xlib, gtk, is but the langage itself is not. If they want to avoid C because it is bloated, then they throwed the baby with the bath water.
Sure, C is becomming an inadequate langage for many things. But moving to a portable assembly is ROTFL.
Cheers,
--fred
1 reply beneath your current threshold.
I'm sick of the "virtualization" of these hardware pieces; why don't we start seeing some "real" hardware? Better yet, some "really good" hardware that really performs well.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
they already tried this. CD32.
unfortunately the example is almost all non-code assembler constructs and library function calls. There is a section that really has instructions.
;draw alpha blended circles
/., what's the deal with no <pre>??? We are geeks for crying out loud.
ncall cnt,add,(cnt,pix,0:-)
clr xy
cpy WINDOW_SIZE,wh
cpy RGBBLACK,col
ncall pix,fbox,(pix,xy,xy,col,wh,wh:-)
repeat
ncall pix,foval,(pix,xy,xy,col,wh,wh:-)
add BLENDINC << 24,col
add 1,xy
sub 2,wh
until wh<=0
You've got to like a language with built in emoticons. The repeat is a little higher level than most assembler, but nothing a good macro system from the old days wouldn't support.
And
The Java VM is a stack computer. The advantage is that it can run on any processor with 2 registers, and works well on x86 since these are also stack-modelled computers (with more registers).
C compilers (gcc at least) use an infinite register model as an intermediate compilation form.
This is easier to compile to, but the vm or JIT has to do more work in making it native. Especially on x86. Alpha and Powerpc have architectures that map more directly to this model.
I'm pretty sure that both architectures are fully translatable into one another.
If I remember correctly Gnu/gcc have a cross platform assembler that feels in the same ballpark.
This thing may be a lower level language than many, but it's still not true assembly.
This doesn't mean the transparent window thing isn't cool, though. I'd enjoy being able to code with reference documents visible through my coding window. No window switching...woohoo...
-PARANOIA is fun. D20 is not fun. The Computer says so.
-The Computer
1. Integrated Ethernet as well as a modem.
2. Integrated DVD
3. Integrated Radio Tuner (both for internet radio (shoutcast, Real Audio and M$ stuff), and AM/FM...
4. CD player complete with visualizations
5. 30-40GB harddrive for video and audio storage (Rip above CD's into MP3!).
6. Ability to pop up caller id on screen in regular TV mode or A/V mode.
7. Game support. Be it Dreamcast, PS/2 or Gamecube games (pick one of those three....we don't NEED another console game format.).
8. RF keyboard with trackpoint.
That would be one killer box. It would be popular with the geeks AND grandma (for pure internet stuff) would like. I think Amiga can do it. This kind of box sure would be nice though!
Gorkman
Of course, this generic computer is of 1970's vintage capacity, and wouldn't be much use to many programmers today except as an academic exercise, but he's working on a new version, MMIX, that more closely resembles a 64-bit word RISC processor.
The thing is, on modern processors, it is practically impossible for anybody but an autistic savant to really write efficient code at a machine level. With multiple execution units, long piplines, VLIW processors like the Crusoe, out of order execution, etc., the very idea of trying to control the hardware directly for efficiency's sake is insane. You'll never be able to do it without an enormous intellectual investment in understanding how each chip works, and then your carefully hand-optimized routines would be wasted effort when the next generation chip comes out (probably about two weeks after you've finally figured out the last one).
This is a perfect example of where the hacker ethos of not reinventing the wheel comes in. Let the compiler designers invest that intellectual effort and just use their work.
A faster compiler or interpreter. If you send C source out to people, they have to compile/link before they can run it. If you send C executable out to people, you have to know what processor/OS/etc they are going to run it on.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
hmmm, shouldn't be too hard in Perl... submit a patch to Rob.
"Free your mind and your ass will follow"
"...unlimited registers, register naming, high-level looping constructs, a tool-based architecture, and object-based assembly programming,..."
Unless Amiga has made some serious changes to the processor as we know it, I dont necessarily think that this is a good thing. High level looping constructs? The reason that we code in ASM (when we HAVE to) is that it runs very quick. With these higher level capabilities, I am curious as to whether this will slow down the speed.
While I think this would be a cute idea, I am not ready to accept these new gifts if they would cause the purpose of ASM coding -- speed -- to fall short. Has anyone heard of any bench marks or information as to how these higher level capabilities could effect the speed of ASM?