Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Amiga

Analysis of Amiga Virtual Processor ASM 135

Posted by CmdrTaco from the stuff-to-poke-at dept.
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.
This discussion has been archived. No new comments can be posted.

Analysis of Amiga Virtual Processor ASM More

Analysis of Amiga Virtual Processor ASM

Comments Filter:
  • 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.
  • I suppose that you're joking but for your information here ISA means Instruction Set Architecture and has nothing to do with the ISA bus.
  • 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.
  • 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.

    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. ;) It's an old buzzword just waiting to be reborn.
  • C is not a portable asm language. Tool.
  • is that it does not look like any assemble code I have ever seen. It looks more like PASCAL to me: ;event loop repeat ;wait till msg arrives ncall app,getevent,(app,-1.l:avo,msg,evt) continueif avo=0 ;pass out to event handler ncall avo,event,(avo,msg,evt:-) ;free event ncall ave,freeevent,(ave,msg:-) until evt=EV_QUIT And some key words sound really odd: qcall sys/kn/dev/lookup,(avename.p:ave,app) ifnoterrno ave,true ;open ave ncall ave,open,(ave,app,0,0:app) ifnoterrno app,true ;open toolkit ncall ave,opentoolkit,(ave:tkit) if tkit!=0 ;get application props ncall app,getprop,(app:prp)
  • 1985 Amiga ASM looks like readable C code.
    Surprise surprise. Been there done that.

    /sarcasm/Modern/sarcasm/ computers are based on trying to fit a solution through the guts of a calculator.

    The Amiga design was an environment. Registers had meaning. There's an Amiga like project now that has about 800 of them. You know why? Because people no longer masturbate over complex designs. Just send the signal and get it over with already.

    This can be applied to audio, video, databases, 3D, you name it. Just resist the temptation to generalize and you'll make a kick ass machine.

    Intel's arch and even RISC force the software to create the environment which causes a ridiculous waste of resources. Transmeta's an exception I'll note. Their software layer seems thin enough to be able to compete with "modern" tech, but it also generalizes beyond the point of no return.

    Modern hardware is like botched microkernel. It splits the machine into a thousand components instead of having a basic foundation to support software.

    Amiga style is Top-Down which makes a lot of "advances" unnecessary since all they are is hacks.

    Oh and say good bye to Megahertz and Gigahertz and High Speed buses. The new (old really) generation of hardware will be labeled "can record 4x better than CD quality" or "can give you smooth graphics or "can quickly find information". Capacity and pure performance based decisions are obsolete.

  • If you can spend that much energy and time to write up all this bull, why haven't you bothered to spend measly 5 minutes reading the Amiga One specs. You could have saved yourself a lot of embarresments...

    ... next time, just keep quiet, ok?

    Bjarne
  • ...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.
    --
  • In the original Amiga there was no low-level. The hardware was built to be a C machine. It was called ASM only because of the funky comma delimited syntax.

    As a result coding the lowest level of the machine was accessible to layman unlike these modern "calculators".
  • This is a Great idea.

    You'll be happy to know that that's exactly what they do; the SDK ships with compilers for C/C++ and pJava.
  • I believe it would be the compiler itself that is the bloat. I don't think past compilers did alot of optimization the way modern ones do. I believe modern optimization algorithms have to keep large chunks of the code in memory while it's compiling and seek out optimizations by sifting through the RAM contents for fast execution. In the past, this would have been absolutely out of the question because RAM was scarce and you couldn't use it up like that. Nowadays... well we know things have changed, so the all these new algorithms, optimizations, etc have created the bloat the previous poster was referring to.

    Just my thoughts... :-)

    -----
    "People who bite the hand that feeds them usually lick the boot that kicks them"
  • > What does this give me that C does not?

    IIRC, it gives you runtime portability across various hardware a la java. (but without the bloat and sloth)

    It's translated into native code, yes, but not at compile time.

  • Ummm, this language kicks arse compared to C. C looks quite toy-like compared to this language. (This is not a flame, just the truth)
  • This is going to sound a bit goofy, but I think that having the language support an unlimited number of registers is a good thing. Anyone who actually thinks a computer has infinite memory shouldn't be programming anyway, and even if some of these "registers" are virtualized outside the CPU, it still provides some flexibility in how a programmer uses the architecture, and how a CPU or machine might be optimized to run this sort of virtual code (e.g. providing fast internal "register memory" addressable with special instructions). In fact, I think some of the Hitachi SuperH series (and probably others as well) can be configured to use part of the cache as work memory, which would probably work well for this sort of virtualization. Also, even if the language doesn't limit the number of registers, that doesn't stop a programmer from finding ways to use as few registers as possible. Still, I think there should be some concern about how well this assembly language maps to real hardware. Even so, some people just like the way assembly language works and probably won't mind virtualization too much.
  • ... does these fools constantly try to push these non-linux stories?

    Everybuddy knows that /. isn't a serious fora anymore. Anything that hasn't the Stallman Seal of Approval gets the axe on /.. Be it QNX, BeOS or Amiga... hey... even xBSD gets slashed once in a while.

    ... well... except when your name is Apple og Sony, then you get a lot of free add's and praise from the same lot who just finished trashing the newest non-GPL tidbits.

    So submitters... pleeeeeease stop pushing for those stories... the /. crowd have become to narrowminded to fathom the scope of what's happening outside the linux world....

    ... time to loose some karma...

    Bjarne
  • What does it give you? The Amiga name, mostly.

    No, this isn't flamebait or a troll. The Amiga name may be enough for you, and I'm not going to be the one to tell you you're wrong (if for no other reason than fear the Amiga zealots will hunt me down and hurt me). :-) Some people will worship it because it involves Amigas (and some will hate it for the same reason).

    Any road, it actually looks like a decent enough language, and as anyone who's coded anything more complicated the Hello World will tell you, C has some problems--which is why we have C++, Objective C, C#, Java, and a wide range of other C-like languages (each with it's own little "something" it tries to add. We don't have a GREAT need for one more, but we didn't have a GREAT need for Gnome (and yes, I know all about Qt and it's "problems" and I stand by my opinion). But we're getting it, and a C-like language that tidied up a few of the messier bits, yet kept C's focus of being fast and (comparitivly) low-level has some merit. I've tried a lot of languages, and I still haven't found the perfect one yet. Maybe this will be it. Or not.

    Certainly no use getting all sweaty about it, and from the look of the moderation already flying around, some people have already lost any objectivity. :-)

  • from the article:

    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?"

  • The point of this (Score:4)

    by victim ( 30647 ) on Monday November 06, 2000 @04:32AM (#646683)
    This article doesn't really convey the point of the Tao Group's [tao-group.com] 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))
  • C has not gotten out of control. Last time I checked it was an ANSI standard, and has remained the same for ages!

    As for C compilers, they are not getting bloated, they are only getting better. We know now a lot more about compiler theory than ever before, and thus the source code to a compiler like GCC would be highly organized and structured to deal with the complexity of implementing a modern C compiler. Today's compilers contain many improvements over the old compilers, including better optimization techniques, dynamic link libraries, and so on..

    It is just %#@%^$* hard for a programmer to produce optimal code in assembler, since he has to worry about the cache, pipelining and other aspects of modern hardware. This is why assembly source code produced by a modern C compiler is usually faster than source written by a human. Contrast that with your old Amiga C compiler that probably produced dog slow code.

    In my opinion, VP Assembly was designed so that it is easier to make compilers for the Virtual Processor. Another advantage is that the programs are smaller in size. The idea is similar to the old VAX instruction set, (where the VAX set has instructions that resemble high level language!) It is a really old idea, and a pitfall I might add.

    VP Assembly will not replace C...
  • Emulation? Who on earth are talking about emulation? Except ThePeopleWhoHaveNoClue that is.

    You haven't grasp'ed the concept, and you'll propably never will...

    Bjarne
  • No coding on x86 is about compactness and discipline because the x86 is brain dead.

    You're not programming a calculator based machine.

    Spend the two hundred dollars on an Amiga 1200.
    The thing is an environment from the start. Fewer chips than a RISC architecture.

    I just bought mine a while ago. I swear it outruns my Athlon 500 because it doesn't waste time on juggling library calls.
  • Could somebody explain what's the point, please?

    Uhhh... cross-platform anyone?

    How is this supposed to compile into faster native code than java application compiled into native code?

    That's not really the point. The point is [see above]. And java is poorly designed in this respect. I would say the Tao group's VP is much more intelligently designed as well(Inferno is another good example of good design).

    -----
    "People who bite the hand that feeds them usually lick the boot that kicks them"
  • The above is a nice, well packaged answer to a whole thicket of questions; it deserved at least the +1 bonus from a registered-user post.
  • 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 #1 bonus you get, is that it includes a portable/ported set of libraries that allow you to do graphics, sound, and many other features not included in the C library.

    It also lets you:

    • interoperate with other languages easily
    • use the nifty tool/library system
    • give one binary to all users, for whom it will automatically be compiled for their architecture
    • avoid the packaging issues of Java while having a Java level of portability
    • easily write compilers from custom languages to this one.
    • etc.

    I could go on, but of course its not perfect, and has several factors that may lead to its demise.

    Its use of user-made event loops instead of built-in mechanisms is just one weakness I noticed in this particular document...

    Its current reliance on Linux as a development platform probably isn't helping much either... they are taking a small percentage (Amiga developers) of a small percentager (linux users) of the computing market and hoping for development...

    "Nevermore, quoth the raven"

  • Stop calling it Amiga ffs ! (Score:1)

    by Anonymous Coward
    In marketing it is a big no-no to use the name of a successful product for something new and unrelated.

  • Never need to write code again?

    Write code the way you understand it?
    Not the way the computer understands it.

  • So you are *totally* oblivion about the Eyetech's A1200/A4000 add-ons?

    So you are *totally* in the dark what beast AmigaDE really is?

    And finally... you've got no clue to what "emulation". If so... MUI, GTK, AnyAPI would be emulators...

    Now... go away... I think your mom i calling for you... time to be breastfed...

    Bjarne
  • I loved the original Amiga back when I was a young dude but the biggest problem facing me was that the development tools and documentation cost MONEY. That's the great thing about Linux, it's free with a small f. I'm not going back to the bad old days of worrying about whether I can afford to develop stuff, however great the technology.
  • 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.
  • Time's wrapping around the corner. Not they try to make assembly a high-(or at least, middle-)level-language. Perheaps it works this time, since machines are not that damn slow as they where at the good old time of the symbolics LISP-machines. But at least LISP is a minimal language...
  • Guys, this new assembly language IS NOT a language for some new fancy Amiga. It is a VM environment designed for an Amiga OS running on other platforms. This has almost nothing to do with C or assembly; it's more about a new, hackerish Java. That can be compiled into native bytecode. *grin*
  • Just warn me as to when I should dust off that copy of Workbench 3.3 and Scala Multimedia.

    Of course, the new Amiga can't be any worse than the old ones; those geezers ran on a 68040!

  • 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.

    I see nothing in what you described that the C language does not offer provided your compiler has a good optimizer.

  • If all you're going to post is yack about something you don't use don't bother.

    I got tired of it from windows losers who said:
    "Microsoft makes the best software don't bother."
    (Oh please, I want a nickel for every tim the paper clip suggested I saved my work before crashing office)
    or
    "Microsoft owns everything don't bother"
    (Hah PalmOS runs on almost all devices)
    Just save it for someone who gives a shit.

  • Syntax is beautiful

    LINE = 80 SPACE
    SCREEN = 25 LINE

    SCREEN;

    That's Forth syntax

    What could be simpler?
  • 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.

  • EOD (Score:1)

    by Mekanix ( 127309 )
    You have nooo clue...

    Bjarne
  • > > But moving to a portable assembly is ROTFL.????

    Meant funny as hell. Seeing anyone enthousiast on GUI programming in assembly reminds me my great 1985 Macintosh programming tales. :-)

    Cheers,

    --fred
  • This only points at your lack of reading skills.

    You keep jabbing about that AmigaDE is just an emulator, how AmigaDE is not a "True Amiga" (whatever that is), jabbing about how it's only PPC and not 68k, x86, jabbing jabbing jabbing...

    Oblivion to the fact that you can continue to use your Classic Amiga (Eyetech). Oblivion to the fact that it's not an emulator. Oblivion to the fact that it runs on "*any*" processor, oblivion to the scope of what's happening here. Jabbing jabbing jabbing like another clueless sheep.

    Now... I've repeated myself for the X. time, and I won't be surprised to se you respond with the same jabbering once again.

    Thus, EOD. There is no gain in trying to educate you. Now, go play with your pal Tim Rue...

    Bjarne
  • > You seem to be missing the point

    Probably. This was more a funny over-the-head overreaction. I didn't really want to trah it. Hey, I even read the MMIX (the assembly used in Art Of Computer programming vol4 and up) on-line chapter.

    > [] 20 hours later it's a 1088 byte executable.

    :-)

    Don't get me wrong. I understand the intereest of a portable assembly langage less fucked (maybe that's not the word. It should be 'more langage neutral') than the java virtual machine runtime.

    Cheers,

    --fred
  • 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.
  • I've got unlimited registers too... I call them RAM.
  • ... well... I'll do it quick, since you can *read* most of the stuff elsewhere...

    Firstly... your ramble about PPC, x86 etc... Well, mister wise-guy... AmigaDE actually *runs* on x86... and a lot of other CPU's...

    Secondly... you can use your beloved Classic Amiga to run AmigaOS 3.9, 4.0 and AmigaDE...

    Thirdly... if all goes well... you'll be able to run your classic apps just fine on AmigaDE...

    Lastly... well... just get your finger out your butt and use WWW to something constructive... like *learning* what AmigaDE is all about...

    Bjarne

  • Re:I don't get it.. (Score:3)

    by Junks Jerzey ( 54586 ) on Monday November 06, 2000 @05:00AM (#646712)
    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.
  • I would like to buy Amiga name and possibly
    rights to AmigaOS source code, and do following:

    1) publish the AmigaOS source code under GPL
    2) make a really nice Linux distro under "Amiga-Linux" name.

    If old Amiga funs get their hands of the newly GPL-ed AmigaOS and develop it further, I would
    let them do whatever they want under name
    "Clasic Amiga OS" or AmigaOS for short, and
    any hardware they come up with would be allowed to carry a name basically at no charge as long as it passes compatibility testing...

    Since I don't have much money... How about 1000$ for the company?
  • Well that's all nice but mostly impossible or impractical business-wise.

    1. Set top boxes have to be priced cheap, 400$ is the absolute ceiling if you want your product to even be placed on shelves.

    2. CD Ripping is a gray area thanks to the RIAA, don't expect to see it in a set-top box, it would merely take a few instants to bury the new Amiga in lawsuits and drive the whole thing into the river.

    3. Console emulation just won't happen unless they plunk down zillions of bucks down Sony/Nintendo/Sega's whoring throats in licensing fees, making the whole thing unappealing to Amiga's finance and marketing departments. The higher your cost, the higher the selling price.. the higher the selling price, the less it will sell.. end result : big loss.

    4. Don't expect to see a 40g hard drive in there anytime soon. I just bought two such drives for about 200$ each. Many set-top boxes sell for 200$ total. The most space I'd see for now is 15g at around 60$. Remember the key factor in acceptance isn't even quality, it's low price.
  • Wouldn't it be better to compile C or whatever language just to the level of the optimized abstract sintax tree/three way instructions and save it as a VM code rather than try to invent another incompatible language?

    Just my two cent euro.
  • Could somebody explain what's the point, please? Why would I want to code in assembler if it will still be executed by VM or compiled into native code? How is this supposed to compile into faster native code than java application compiled into native code? [Java is higher level language and therefore compiler has *more* space to make it's optimizations. If you code in virtual assembler that is then compiled into native assembler compiler doesn't have that many ways to optimize code.]

    I think it's because of the example - graphics with alpha channel - people get so excited about this. And this is 'cool' only if you are limited to X11! Even in that simple example the code looks pretty hard to understand when compared to equivalent C(++) code. In the end, if all you are interested in is speed you have to use native assembler. Otherwise simply use C(++), Perl, Python or Java - all of those have "unlimited registers" also.
    _________________________

  • High level looping constructs?

    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 [tuxedo.org]). 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.

  • just like i said ... you are on of the many STUPID STUPID eggheads who don't know what they are talking about .... try reading something before crying some crap ya moron
  • C: "a language that combines all the elegance and power of assembly language with all the readability and maintainability of assembly language."
  • The first one, actually -- the position for the second is still open.

    Unfortunately, the 'dot in .com' [sun.com] position was already taken :(
  • First off, if one wants to rip their own CD's, who cares? I know the RIAA does, but personally, I think they are really after Napster, and soon, there may not be enough water there to for them to continue the case (well, I am hoping anyway at least with recent things happening with Napster).

    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.....).

  • while I think the syntax is ugly and obtuse, Forth actually IS used in stuff... a forth system is used for the firmware in Macs and Sun boxen

    ------
    http://vinnland.2y.net/
    Vinnland - A country of True Freedom.
  • Well, I'd amend that a bit, myself.

    Remember MAME? It's a software emulator of very specific hardware characteristics. Now, I don't know just how defined the Amiga architecture is in this new release, but it's certainly possible that you may be able to know clock cycles in this virtual assembly. They're wouldn't be 'real' clock cycles, they would have to be emulated, but for probably 95% of the problem set that's fine.

    If you get into needing hard real time, you have to be hand-writing to the bare metal anyway. This virtual assembly wouldn't do the job. This is portable and hard-real time can't really be portable -- you have to recode it to every new hardware environment. This is not TRUE assembly and won't cover all of the bases that the real thing will, but depending on their implementation it could be guaranteed that this demo would always APPEAR TO run at, say, 50fps on any machine that is 'officially supported'. I don't know that this is true, I'm just asserting that it's possible. Again, see MAME.

    It's also worth pointing out, as an aside, that this language seems a lot more readable than C.

    Looks to me like they could get some pretty good performance out of this beast -- along the lines of C code, but fully portable across any platform that's fast enough.

    When I first heard about this new Amiga, it struck me as the stupidest thing I'd ever heard. ("That's not an Amiga, wtf are they thinking??") -- but I'm pretty intrigued by what I'm seeing. Doesn't matter HOW you get where you're going as long as you get there -- and if they can bring the crisp, lightweight, but powerful feel of the Amiga back to modern computing, cool. :-) Hope they get wildly rich. :-)

  • The above post is VERY insightful. C is becoming a bloated mess of a language and shouldn't be used unless totally neccessary.
  • I actually had to explain the Golden Showers comment to my wife last night. Damn, she is such an innocent. (Hehe, but I'm working on that problem.)

  • "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
  • Have you read slashdot lately?

    Bjarne
  • Comment removed based on user account deletion
  • Why won't you people let the Amiga die an honorable death?

    Die Amiga!!! Die!!!
  • I think the idea here is that the VP is supposed to be an intermediate code. By not limiting the number of registers, it'll be easier to translate it into future processors which will probably have more registers.

    It's a lot like the Java Virtual Machine, excpet the JVM has no (general purpose) registers, for, I would think, the same reason.

    --t

  • 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"

  • Exactly! Everybody here keeps saying "why don't I just use C or Java" .. I can't believe that everyone seems to really not see the incredible possibilities of a platform independant assembly language.

    Java is a great, feature rich, high level language, but even with JIT you have to recompile the program every time it is run, and just this demo has convinced me to can do much more low level stuff than with Java. (Also I have read that the new Amiga DE has a built in, blazingly fast Java VM)

    And C? Sure, you can distribute your source code (which often takes a lot painstaking work to make it truly portable) and let people compile for their native platform, but your average user doesn't want to have to compile programs, they just want to run them... and the entire world is NOT open source, I'd much rather distribute a platform independant binary like Java byte-code or this new Amiga Virtual Processor code, which will compile once, optimized for the host system which runs it. And from all reports thus far, Tao has done a phenomenal job of making the technology live up to its promises and run error free. (I love Java and use it for everything these days, but anyone who thinks Java is bug free is smoking crack)

  • Firstly, to tackle the issue of unlimited registers. I am guessing that you don't need to use unlimited registers, and the registers you create are assigned to actually physical registers as needed. However, say you were working on a 68000 platform with 8 data registers, and 8 address registers. There would be nothing to stop your from only declaring those 16 registers, and nothing more. This is of course assuming that the compiler is intelligent enough to have those values constantly mapped. The fact that the rest of the language is not proper ASM would cause problems because it would require the use of particular registers in order to carry out the function. So, you would not be able to perform nice functions like loading often used values in a procedure into the regaisters because its very likely that the higher level / macro type functions will remove them. What I would LOVE to see (and I am sure a lot of people would agreement) is a whole new platform altogether. A brand new processor, a new OS, new apps built from the ground up from what we know is required today, and with what we know will be required tomorrow. I could see something like this being a hobbyist machine for the longest time, and relatively expensive, but given the open source movement working in a brand new arena would attract people, and as a result, attract applications. The Amiga was earth shattering when it came along, in a day when a new platform could be released and obtain market share. The idea of just using VM's is nothing new, and from most point of views, not too efficient. I'd kill to get some new platform, and new development tools, and hack away like the old days......... aaahhhhh........
  • 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).
  • ... you still have no clue...

    .. your loss... our gain...

    Bjarne
  • I don't think I have ever used a C compiler that takes any notice of the 'register' keyword. As far as I know, it has been made pretty much obsolete by advances in compiler technology.
  • Whoa dude, su-weet link! Thanks!
  • 10-20 users ?? I know that there arent millions of us left, but i bet its more then 200000
  • Yes please, post some examples of VP code, I'm a little skeptical...
  • You st00pid slashdot linux usres need to read up on something before you start screamin "Amiga is dead" The Amiga might be the thing Linux needs to beat Windows !!

  • It's called a macro-assember. You can still use jnz or beq or whatever the equivilants are if you're sadistic.

    BTW, I've started a port of the Linux Kernel to the Amiga VM. Hopefully you'll be able to run X-11 on the VM in the near future! E-mail me if interested.

  • The reason that this assembler 'like' languge isn't as low level as a 'normal' assembler is because of the multi-platform nature of it.
    It's as low as you can get to the hardware, when you _don't_know_ what that hardware is.

    Different processors have different numbers of registers, so doing thing this way, you are able to get code as fast as possible, while taking full advantage of whatever hardware the end user decideds to run it on. It could even run on a processor that didn't exist when you wrote the code.

    As has been demontrated by the Amiga development guys, you can take a disk with a one file program on it, written using Amiga VP code, put it in an x86 Windows machine and run it, then put the disk in a PPC Linux box and just run it. I don't see that happening with 'normal' assembler.

    --

  • Amiga and hardware (Score:3)

    by ajs ( 35943 ) <ajs.ajs@com> on Monday November 06, 2000 @05:38AM (#646743) Homepage Journal
    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!
  • ...you could call it `C`?
    It sounds more like a java bytecode interpreter with an assembly-like front-end.

    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?

  • Realistically, there should be no reason the average programmer should need or want to code to assembly language on the Amiga (any more than she would use assembly on the x86, or write raw bytecode for the JVM). Thus, the real test of the Amiga system will be its suitability as a compiler back end. How does it measure up there?

    Other posters point out that many of the constructs touted in this article were common features in older assemblers. This hints that many of them are more useful to the assembly programmer than to the compiler writer. If the dynamic translations being used do an equally good job generating e.g. loops from looping constructs and from explicit branches, this should make little difference in practice. If, however, there is a penalty for using one or the other construct then we must expect either 1) poor high-level language support or 2) assembly programmers to ignore the high-level constructs in favor of more efficient low-level constructs.

    The biggest potential of the VP code lies in establishing flexible calling conventions. Every procedure is allowed to establish its own conventions for passing arguments and returning results. This combined with the assumption of infinite registers allows very simple and reasonably efficient high-level language compilers to be built. Moreover, by passing all arguments in registers, it should be easy to make multiple languages interoperate smoothly. This is because there is no need to establish conventions about the shape of the stack, the location of the return value, and so forth when a call is performed. This is handled by the underlying assembler.

    An additional advantage of the infinite-registers assumption may be the ability to "registerize" global variables and return values. Most compilers must keep global variables in main memory; if we were to keep them in registers, independently-compiled files (like libc!) would not understand which registers were in use. GCC provides special system-dependent ways of doing this, but they're dangerous and fragile. In principle we can perform register allocation for the entire program in one go when we dynamically compile it, and this concern goes away. I suspect it may still be impractical to do so in practice. Registerization of return values, however, is very easy. We simply declare multiple return registers as shown in the example code. The biggest concern here is that there is simply no way to declare this in C! Thus, very few C programmers are likely to be able to make use of this optimization---it is much like gcc's reg-struct-return optimization flag.

    What C programmers do now to return multiple values is they pass pointers as function arguments. This raises the biggest unaddressed issue in this article: how _does_ the stack work, anyway? We presumably can't take the address of a register, and a C compiler must therefore be able to declare and use stack memory. It's not clear how that can be done, though there is presumably some way of doing it.

    It's also unclear if we can get our hands on the real VM state. For example, many garbage collectors (eg the GC in any decent Java implementation, but you can name a statically-compiled garbage-collected language as well) need to walk the stack and index garbage collection tables to discover live variables. They then need to find the memory or registers which contain corresponding pointers. How can we do so in Amiga VP code?

    This article raises more questions than it answers. I'm not encouraged by presentations which talk effusively about how easy it is to program in assembly language; no assembly, however easy to code, is going to become as widespread as C in the near future. If the Amiga VP is to become a popular target, there must be solid compiler support. It must also be attractive for compiler writers and library authors to re-target their own work to the Amiga VP---and that probably means answering questions like the ones above in a widely-accessible forum.
  • 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,
  • 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 =:-)
  • > 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

  • This is not emulation, emulation is recontructing a hardware architecture in software so you can run code through it. This is something which takes a platform independant low level language and compiles it into NATIVE code specific to the host system.

    Real hardware than performs well? What, like an Athlon 1.2 GHz? I would say most hardware out there performs "really well"... 99.9999% of the world's computer problems are software related. (*cough* Micro$oft *cough*)

  • Why can't you just compile C down to the bytecode that this assembler compiles to? The question is why should I use this language instead of a more normal language, not why should I use this bytecode/VM combo
    --
    Mike Mangino
    Sr. Software Engineer, SubmitOrder.com
  • People have done this before, but always fucked it up by either: Giving up control of the platform and letting it get un-standardized such that the write-once/run-anywhere thing fell apart. It happened to the UCSD p-system, and it happened to Java. I hope Amiga manages to hold this together. I think they are doing good by making the development environment themselves. I really hope this works, because
    A) i like their philosophy
    B) i really liked my old amiga, and it looks like a lot of the things i liked have carried over.
    C) I really want to write multi-platform network adventure games, and Java suxx...
  • Please, people, remember what history has taught us! Emulation is not the efficient way! Just look at what happened with the Virtual Device Driver, Virtual 3D Acceleration (that pathetic video card known as the S3 ViRGE), Virtual Machine, Virtual Modem Controller, and the Virtual Sound Device (otherwise known as AC97).

    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.

  • they already tried this. CD32.

  • I don't think programmers will program in this assembler, except for maybe the odd time critical inner loop, but I even doubt that. Those days are mostly gone. (eg. Doom had assembler inner loops, Quake I believe does not.)

    If you are using this environment then your compiler will generate this assembler in its back end. The reason for high level constructs such as the virtual registers, looping constructs, and method dispatchers is to avoid choosing a mechanism too early in the code generation process. These mechanisms are chosen by the backend code generator which knows your processor details.

    To compare to java... The java byte code is designed only for Java and must pass certain proof conditions to be acceptable to the runtime. This makes it inefficient or nearly impossible to implement many languages. For optimizations it has a similar split. Good java compilers will optimize at the compiler level what they can. Good java runtimes will optimize from the byte code down to the machine. Very similar actually.

    For the example code. I agree, X (and Windows) both have sadly impoverished drawing environments. Probably one of those things that until programmers see what a better environment is they don't believe it exists. I come from one of those fuller environments and am frequently bamboozled when I find X is missing some basic graphic construct I was needing.

    Tao has been out there for years Taoting this environment. Its only when alpha channel amiga balls show up that the thousands of /. geeks take notice. I'd say the example works.
  • unfortunately the example is almost all non-code assembler constructs and library function calls. There is a section that really has instructions.

    ncall cnt,add,(cnt,pix,0:-)
    ;draw alpha blended circles
    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 /., what's the deal with no <pre>??? We are geeks for crying out loud.
  • 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.
  • Umm, isn't the point of programming in assembly that you know EXACTLY what is happening at the lowest level? You know that there isn't any overhead to any of your operations. The idea of unlimited registers is nice and all, but unfortunately, the CPU has a finite number. That means that there will be some routine assigning the registers for access at any given point in a program. Um, that's not a register. It's a variable.

    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...

  • I know it may be beating a dead horse (Amiga) but it's still cool that they are around, even though they have maybe 10-20 users (ok, maybe my numbers are pure conjecture, but who would use these things anymore?). I think if the Amiga has a shot, it's in the set box top area where there's no real leader yet. To make a winner of a set top box, here's my suggestions:

    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!

  • The structured if and while blocks are assembler macros.

    And under most modern OSes on modern CPUs, even in native assembly you still don't know very much about what's going on anyway. You could be put to sleep for thousands or millions of cycles while other tasks execute. Your next memory read could come from L1 or L2 cache, RAM, or even from disk. Your next conditional branch may be in the pipeline already or it may cost you dearly - even between different CPUs of the same family, even between successive runthroughs of the same code. We're not talking the 6502 here - do YOU know how many pipeline stages a given instruction breaks down into on the Pentium III? Athlon? Duron?

    In the face of all that, I'd think this VP system would be a relief - at least you're no longer expected to worry about what happens at the pipeline level. :-) Besides, the theory is, the VP-to-native translator will (and should!) know more about the cycle-by-cycle behavior of your CPU than the programmer who wrote your software.

    Or I could be talking out my ass again. :-)
  • Any programmer worth his salt has heard of, if not read, Donald Knuth's "The Art of Computer Programming". All the examples are written to a hypothetical target machine, MIX, in a generic assembly language. You can get simulators for it for many platforms.

    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.

  • This thing may be a lower level language than many, but it's still not true assembly.

    Actually, it's really more like C. Assembly language is SUPPOSED to represent the actual machine code. It's about the closest thing to programming in raw hex numbers.

    What they showed was more like C really... it had structured if and while constructs, variables^H^H^H^H^H^H^H^H^Hunlimited registers. HOw is this ANYTHING like assembler? Those kinds of constructs tend to require the generation of code, and any code that's generated that the programmer is unaware of is bad because then the programmer doesn't know what's really going on.

    Normally, this really isn't a problem, but when you're writing something that's timing dependent, like a device driver, you actually do need to know what's going on AT THE PROCESSOR LEVEL. Otherwise, there's no guarantee that your program will meet the timing requirements.

  • What does this give me that C does not?

    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.


    ---

  • hmmm, shouldn't be too hard in Perl... submit a patch to Rob.

    "Free your mind and your ass will follow"

  • I dont necessarily believe this is a good thing... (Score:3)

    by Lostman ( 172654 ) on Monday November 06, 2000 @04:20AM (#646798)
    "...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?

Slashdot Top Deals

...there can be no public or private virtue unless the foundation of action is the practice of truth. - George Jacob Holyoake

Close