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.
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.
"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.
C is not a portable asm language. Tool.
Giving IE users a taste of their own medicine since 2005 - http://pods.-is-a-geek.net/
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)
Together, we are strong; Apart, we are stronger.
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.
The message on the other side of this sig is false.
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.
--
-- Virtual Windows Project
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".
The message on the other side of this sig is false.
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"
Higher Logics: where programming meets science.
> 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.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
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)
Everything is but a number spoken by itself.
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?
/. 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.
/. crowd have become to narrowminded to fathom the scope of what's happening outside the linux world....
Everybuddy knows that
... 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
... time to loose some karma...
Bjarne
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. :-)
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?
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.
The message on the other side of this sig is false.
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.
Decentralization: the brief interval between the decline of one centralized regime and rise of another.
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.
It also lets you:
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"
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.
The message on the other side of this sig is false.
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...
--The knowledge that you are an idiot, is what distinguishes you from one.
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*
Black holes are where the Matrix raised SIGFPE
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
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.
Will I retire or break 10K?
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.
The message on the other side of this sig is false.
Syntax is beautiful
LINE = 80 SPACE
SCREEN = 25 LINE
SCREEN;
That's Forth syntax
What could be simpler?
The message on the other side of this sig is false.
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.
You have nooo clue...
Bjarne
Kudos
Hands in my pocket
> > 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
1 reply beneath your current threshold.
> 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
1 reply beneath your current threshold.
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.
I've got unlimited registers too... I call them RAM.
If tits were wings it'd be flying around.
... 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
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.
-Billco, Fnarg.com
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.
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.
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
The first one, actually -- the position for the second is still open.
.com' position was already taken :(
Unfortunately, the 'dot in
deus does not exist but if he does
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
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.
"I would say that 99 per cent of what my father has written about his own life is false." - L. Ron Hubbard Jr.
Well, I'd amend that a bit, myself.
:-) Hope they get wildly rich. :-)
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.
The above post is VERY insightful. C is becoming a bloated mess of a language and shouldn't be used unless totally neccessary.
Everything is but a number spoken by itself.
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.)
Bite my yammer.
"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.
Have you read slashdot lately?
Bjarne
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.
Why won't you people let the Amiga die an honorable death?
Die Amiga!!! Die!!!
Beware the wood elf!!!
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"
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
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
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.
Trolls throughout history:
Jonathan Swift
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.
--
--- I'm sure using a computer was fun back in the 80's. *sigh*
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.
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,
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
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*)
"Mind, as manifested by the capacity to make choices, is to some extent present in every electron." -Freeman Dyson
Yes, this is possible. See the papers written by Michael Franz at
www.ics.uci.edu/~franz/publications.html
He shows that applying compression to the parsed source tree leads to the smaller files than binaries, bytecode, compressed source, or any other known format. This "slim binary" format is compiled as it is loaded from disk. Since disks are very slow compared to processors, the time spent compiling is made up for by the time not spent loading a larger file. System 3 Oberon on various platforms uses these slim binaries.
Why should I use any VM (let alone the Amiga one) for anything these days? Since most of the world uses MS Windows and/or Linux, there is no point in using a virtual machine, from either the developer's or the user's perspective : -If I am a developer, I would have to invest time and money in learning how to use the new VM, with dubious results -If I am an and user, I would not be interested in the technology behind the program; I would just use the fastest/most efficient program for my job Why not poke away with GCC/Qt or Visual Studio or Qt on Windows directly? The end result would be better from any perspective : -speed -efficiency -effort etc. Instead or using a platform's name(Amiga) to promote a VM product, why don't we all agree on a set of standard libraries for MS Windows and Linux ? That would mean portability between the two platforms. I am referring to those platforms because they are the main ones currently.
You can, however, use 's and
;draw alpha blended circles
's, and 's for example:
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 add 1,xy
sub 2,wh
until wh
Which produces the required result. There will just be line breaking if the window is too small (rather than horizontal scrolling).
John
John_Chalisque
Why would anyone post such a story anonymously.
unless......
"Only two things are infinite, the universe and human stupidity, and I'm not sure about the former."
- if you love something, set it free; if it doesn't come back, hunt it down and kill it
...you could call it `C`?
This is pathetic. Reminds me of situations in which some doctors keep adding equipment and experiments to keep somebody alive, although the brain's fried.
Pleeeeaaaase leave the Amiga its dignity. It was great, but 10 years ago. Let us remember it for the wonderful machine it was. Those deperate attemps at keeping it alive revolt me as a former Amiga user and lover.
When it's over, it's over. Let's unplug the thing.
/max
-- It's always darker before it goes pitch black.
One thing VP has going for it that isn't explicit in other languages is multiple return values. E.g. qcall foo(i0,p0:i1,i2,p2) takes an int and a pointer in, and returns two ints and a pointer. That can be very handy.
...and therefore write cleaner code.
When you want to be able to translate code into its optimal representation for a particular platform, you want to have as good of an idea of what that program does as possible. That way, your translator can "know" what's really going on and optimize your code for that purpose.
Some systems can do floating-point operations faster one way than another. The same goes for loops, graphics, sound, and every other conceivable task.
So, the idea was to break the code down to its lowest level possible, while still maintaining its structure and the intent of the programmer.
So, it's not really assembly language (what do you expect anyway, with a multiplatform system?), but it's lower-level than C, and it is the step right before the VM bytecode.
--------
Life is a race condition: your success or failure depends on whether you get the work done on time.
I came from the c64 underground, and then i got my hands on an amiga.... It was innovative.... As I continued my way into the lurkey business of coding, i've never found anything more innovative then the amiga cli.... You could actualy type something like format fd0 as msdos which worked... Unfortunately i've had to change my amiga 1200 with a funky 68030 at 50 Mhz for a state of the art 486 66 Mhz (Win95 even wasn't out at that time). So, I trid, and i tried to get the same functionality.... Gone was Dopus, Gone was a useable cli, Gone was the proper, powerfull multitasking... Even the stereo sound didn't work properly.... PC Hardware Sucks.... It' s outdated even now. Linux gave me back something of the power an Amiga "With capital A" used to give me (and added something to it even). So.... I've looked at the new Amiga, and I hope they will succeed. At least they made computing fun for a while. LONG LIVE AMIGA C= 4EVER
Let's see: the Java VM is stack-based, the TAOS VM is register-based, the DIA VM (the heart of the Inferno system) is memory-memory-based (I don't remember which memory model is used by the C# VM).
It looks a little bit like the division between the RISC/CISC/stack based CPUs..
In the CPU ISA war, I would say that the RISC has "won" because if you want to create a new CPU you would choose a RISC ISA.
Commercially the 80x86 has won, but this is more due to its huge software codebase than to its architecture.
I'm not considering VLIW because I don't know of any VM which could be said having a VLIW-like design!
A comparison of all these different VM would be very interesting? Which design increase code density, is easier for getting better performances?
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
As a possibility, the /. system could convert
<pre>'s from
<pre>
stuff
stuff
stuff
</pre>
into
<br><tt>
stuff<br>
stuff<br>
stuff<br>
</tt><br>
John
John_Chalisque
I do hope that features like object-orientation and looping constructs are just features of the assembler, not of the VM itself.
People write software in higher-level languages, the lowest of them being C, which still provides more abstractions than the VP ASM. These languages are compiled and for the compiler it is usually not a benefit having an assembler that provides eg looping constructs. Unlimited registers are a different story. They are a good idea, since they let the native code generator do the register allocation (this is why I don't like GNU Lightning, for example).
Another drawback of being high-level is that you may lose the ability to do things that would be possible on a lower level. Example: In the JVM it is impossible to do a tailcall, hence languages like Scheme cannot be compiled to JVM code (at least not without jumping through lots of hoops and thereby losing a lot of performance, like in Kawa). I suspect the Amiga VM has the same problem.
A built-in object model seems to be a good idea for a VM, but only as long as you are using the VM with languages that fit this object model. If you want to use multi-methods (like in Common Lisp) on the JVM, for example, you're stuck.
bye
schani
Hear Hear!!!
;-)
Amiga also means lady friend
Yeah, think about it! This is just a "hey, you wanna see the guts of this..." for a "ain't it cool" sort of thing and for geeks to ooh and aah. Most likely nobody will use the assembly, but will probably use C++ or whatever... Read the article you fuck-nut.
---
Play Six Pack Man. I
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
Virtualizing the hardware allows bullet-proof systems, that absolutely can not crash (IBM S/390 virtual machines, for example), can be painlessly debugged without requiring any debugging info to be compiled into the "object" code (but it helps to have a separate map file), intermediate compilation/assembly into p-code that is truly portable across architectures. You can use other languages to compile and link p-code, not just this VA thing. When you're dealing with multi-processing, especially of the mutant variety described for the PS2, it may be easier to deal with the associated issues at the p-code interpreter level than to try writing a universal kernel. Who cares if the virtual machine "forks", so long as the definition of the VM itself remains stable?
If you have closed-source p-code, you can still throw it on new hardware and expect it to work, without having to buy an upgrade (or worse, curse the fact that the vendor has gone t.u.). You can run the p-code in its own VM with tweaked versions of the libraries it calls to hook in functionality the original author never intended... In other words, it's a new level for geeks like us to play with!
But it's not a revolutionary idea... Didn't UCSD do this back in the '70s? Didn't Sun (Java) do this in the '90s?
[100% ISO 646 Compliant]
SVM, ERGO MONSTRO.
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"
but has anyone done a comparison of the new Amiga (Tao?) VM vs Java VM or vs MSIL? (hell, vs both would be cool... triple threat match)
Java's been around for a while, anyone know if Sun's planning an upgrade? The Federal Govt and an Act of God combined can't stop MSIL from coming... What's to stop the Amiga VM from running on Windows? (or on any of the other VMs?!)
Whywhywhy! enlighten me, plz
--
Peace,
Lord Omlette
ICQ# 77863057
[o]_O
I can see that unlimited registers would be a nice thing in that there would be no need to worry about running out. But - why? Coding, especially at THIS level, is about compactness and discipline, not about frivolous waste of resources. I can see that, because it's a virtual processor, there is less worry that addressing time will increase, and that makes sense. Obviously on a real processor, if you had a few thousand registers, their access time would be vastly varied. But this will surely just encourage laziness?
On top of that, most assembly language instructions actually executed, are those which have been generated by compilers. Which can quite happily get by on a lot less than unlimited amounts of registers. So it's a little wasteful.
On the other hand, so what - who's gonna use it anyway =)
--Remove SPAM from my address to mail me
They've invented a language with high-level loop constructs, an unlimited number of int, long int, float, double and pointer registers, that can use external "library" functions and include extra code for reuse.. and it's translated once into native code for your architecture, and runs compiled after that!
Is it just me, or does this sound an awful lot like C? What does this give me that C does not?
"...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?