X-Listserver: Macjordomo 1b10 - Macintosh Listserver by Michele Fuortes
Date: Tue, 18 Mar 1997 12:21:31 -0500 (EST)
From: Figaro Tea <humphret@lurch.winthrop.edu>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: High-Level Assembly
Stu, your last StuChat made me think about something. I've been thinking about the details of high-level assembly. It would be an entirely new language, like C++, Pascal, Java, etc... I was thinking while I was coding and it occured to me that one of the main reasons people don't program in assembly is that it isn't portable. I thought to myself, "It would be great if the 68K assembly I was writing could be easily ported to the PowerPC." Then I thought of the stuff I was doing in my assembly language class. The assembler we started out with wasn't a true assembler, I discovered this when I was stepping through the program to debug it; it turns out each instruction was actually 2 or 3 processor instructions! I was writing in assembly, in all of its low-level, power-packed glory, yet the code I was writing wasn't a part of the processor's instruction set. Some of the instructions that I was using weren't even in the instruction set in any way at all, like the rotate instructions. I thought that this could really be a true language if it received some more development. Think of it: a high-level language that had all of the power and speed of assembly, but with the portability of C++; it would still take multiple lines to do the same thing as one line in C++ though.
The high-level assembler in this case is called SAL, which stands for Simple Assembly Language, and the processor is the MIPS. In a previous post I talked about a branch instruction that took three arguments so that a separate compare wasn't needed. This particular instruction in SAL happens to be a real instrucion for the MIPS, it could just as well be done in 68K or PowerPC by separating it into two instructions: the compare and then the branch. In fact you would have to do this if you wanted a conditional branch, everytime; so why not have a macro that does it for you in one line. You wouldn't gain or lose anything by doing this since it's just a macro. However, if you were to take that same instruction and assemble it for the MIPS it would assemble fine with no changes, the only difference being that the MIPS will actually do it in one instruction and won't break it up. Does this sound like the way high-level languages work?
Being a higher form of assembly it would still have some of the same restrictions, mainly the tediousness, so it wouldn't replace languages like Java or C++, and definately not the visual languages. The importance is that if you wanted to write that really fast game, then you can do it without the fear that it won't work on any other processor. You can do whole programs in C++, but for some tasks, say databasing, COBOL would probably be better suited since it's geared for it; similar to the way Fortran's geared for scientific work: high-level assembly would have its place, probably for writing games, but whose to say you couldn't use it to write whole programs? Also, being a high-level language high-level assembly would lose a bit of its power in order to become portable; but that all depends on how well it would be written.
I'd love to hear what others have to say about this, I truly believe this could be language in its own right, complete with its own required syntaxes and weirdness. I've already been pondering about how you could use registers, since not all processors have the same number, or even call them the same thing. This is just one of the many hurdles that would have to be crossed, but it could be done. C was invented in 1979, and it took it about 15 years to become C++ and the dominant language in the business, maybe this could be the next revolution!
..._Tim_...
--=[Anything that can be envisioned can be brought into reality.]=--
http://www.winthrop.edu/~humphret
zzhumphreyt@winthrop.edu
Date: Tue, 18 Mar 97 10:15:21 -0800
From: James Hague <jhague@dadgum.com>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re: High-Level Assembly
>I'd love to hear what others have to say about this, I truly believe
this
>could be language in its own right, complete with its own required
>syntaxes and weirdness. I've already been pondering about how you could
>use registers, since not all processors have the same number, or even
>call them the same thing.
I too really liked Stu's macro example in the latest chat. I have a script-driven data munging tool ("Luncher") and I immediately started thinking about how to replace the simple parser with macros.
One interesting possibility is that, like some fancy 68040 assemblers, PowerFantasm could do instruction scheduling (with the help of some directives, most likely). That would improve the code created by simple macro expansion.
On the subject of a high-level language/assembly mix, you can find a lot of interesting info if you dig through journals like Computer Language and Dr. Dobb's from the 80s (little languages were a popular topic). In one article I remember clearly from Computer Language, the author reduced C to a simple, assembly-like subset where each line of code could be trivially compiled to one or two machine instructions. Complex expressions were removed; you wrote code like:
total = count + 6;
total *= 3;
if (total > 500)
total = 500;
There also was some work done on a standard, cross-platform assembly language, but it always stumbled on the big archiectural differences between processor families. Simple things like big-endian vs. little-endian never seemed to get resolved.
James
jhague@dadgum.com
Date: Tue, 18 Mar 1997 13:47:58 -0500 (EST)
From: Figaro Tea <humphret@lurch.winthrop.edu>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re: High-Level Assembly
On Tue, 18 Mar 1997, James Hague wrote:
> There also was some work done on a standard, cross-platform assembly
> language, but it always stumbled on the big archiectural differences
> between processor families. Simple things like big-endian vs.
> little-endian never seemed to get resolved.
It would seem that it would be possible. Essentially high-level assembly would just be standardized macroses. I was thinking that the high-level assembly would be compiled to the assembly for the processor, the same way a compiler does now. The main difference between a C++ compiler versus the assembler compiler would be that the assembler-compiled code would only be about 2 or 3 lines; there could even be an option in the assembler to display the high-level assembly as the processor-assembly.
Like you said in your post, the statements won't be terribly complex so there won't be much room for the compiler to mess up the code; hence it would be like you were really writing in assembly.
..._Tim_...
--=[Anything that can be envisioned can be brought into reality.]=--
http://www.winthrop.edu/~humphret
zzhumphreyt@winthrop.edu
Date: Tue, 18 Mar 1997 18:31:04 -0500
From: Stuart Ball <lightsoft@compuserve.com>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: High Level assembly.
I'm glad that people are looking at uses for Fant 5 that go beyond the obvious.
The main reason d'etre for these changes is to allow cross translation of68k to PowerPC.
We will be supplying new facilities in the macro processor for the V5 assemblers such as allowing access to important internal variables (RS and Globoff counters for example to determine the size of structures), along with better parameter handling (i.e. simple string functions) and some intrinsic variables one can use; probably as simple as "a" (32 bit unsigned integer) and b$ etc following the theory that simplicity=speed. Feedback most welcome in this area - we are listening.
Tim, in Anvil, one can write a translator that operates on text file's as a build phase. Hence stage one could be the translation from "your language" to PPC assembler all at a text level, phase 2 is the PPC assemble phase and stage 3 is the link. This may be a better option for what you are talking about? Better than a macro translation set? Arguable.
The "translator" gets called with a command like:
Here's your input, pass me a handle to the output file and let me know if
you need any more help (finding include files or whatever). Simple?
James, "Luncher" - does this mean it takes a while to run? :-)
>One interesting possibility is that, like some fancy 68040 assemblers,
>PowerFantasm could do instruction scheduling (with the help of some
>directives, most likely). That would improve the code created by simple
>macro expansion.
Also redundant interface code (i.e. macro expansion entry/exit code) could
be optimised out as one does in a real compiler (one hopes!) - like macro
one ends in
stw r3,r20
And then the next expansion starts:
lwz r3,r20
which is redundant. Yes, I agree that additional directives would be required
- something like:
let a$=last_line *last_line is an internal string variable
holding the last line of text generated.
if a$="stw r3,r20" goto m1
lwz r3,r20
m1: etc...
Obviously, the string handling needs to handle wild cards as well. ?
and * where ? means just this character and * means all text from here to
end of string...(I know it's naff, but it works).
>Simple things like big-endian vs.
>little-endian never seemed to get resolved.
Ha, even humans haven't sussed this one yet!
Date: Tue, 18 Mar 1997 19:17:49 -0500 (EST)
From: Figaro Tea <humphret@lurch.winthrop.edu>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re: High Level assembly.
On Tue, 18 Mar 1997, Stuart Ball wrote:
> Tim, in Anvil, one can write a translator that operates on text file's
as a
> build phase. Hence stage one could be the translation from "your
language"
> to PPC assembler all at a text level, phase 2 is the PPC assemble phase
and
> stage 3 is the link. This may be a better option for what you are talking
> about? Better than a macro translation set? Arguable.
Exactly what is Anvil anyway, is it separate and distinct from Fantasm 5? From what you said above I could write some kind of plug that could take my "language" and translate it into PowerPC; similarly I could write a plug to make 68K code from my "language" too? If this is the case then this is essentially what I was talking about in high-level assembly, the only difference is that the language is mine and not standard. So I could write plugs to go from my "language" to whatever processor-specific language is needed, and just give the plug away to whoever wants it, hmmm... I don't want to get too overly excited, not until you confirm what I'm saying, but Lightsoft, you guys may have a hit on your hands!
..._Tim_...
--=[Anything that can be envisioned can be brought into reality.]=--
http://www.winthrop.edu/~humphret
zzhumphreyt@winthrop.edu
Date: Wed, 19 Mar 1997 12:22:31 -0500 (EST)
From: Figaro Tea <humphret@lurch.winthrop.edu>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re: High Level assembly.
On Tue, 18 Mar 1997, Stuart Ball wrote:
> BTW, Figaro Tea? It's not an anagram is it? Have I missed something?
Figaro Tea is just a name I chose, it isn't an anagram, at least I don't think so. Basically it just sounds cool! I can sorta justify it because my first initial is T, and when you say Figaro Tea aloud it can be interpreted as Figaro T.
..._Tim_...
--=[Anything that can be envisioned can be brought into reality.]=--
http://www.winthrop.edu/~humphret
zzhumphreyt@winthrop.edu
Date: Sun, 23 Mar 1997 13:26:32 +0100
From: Lightsoft <lightsoft@zedworld.demon.co.uk>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: FPU maths in 3d Applications
I've posted this onto the list to see if anybody can help out. Apparently CompuServe has gone mad and is send all my mail 3 times, so I'll post this one from Demon and hopefully CompuServe will get it's act sorted out shortly.
Appologies to anybody who's rx'd 3 replies from me today :-(
All I can suggest at the moment Allan is check out Rob's FPU article on the WWW site (if you haven't already) and "IM PowerPC numerics". Anybody up to a quick "summary" to help Allan out here?
Stu.
---------------------
Hi Stu
Silly questions time, I'm afraid. I'm playing around with polygons and suchlike,
and it works after a fashion. But there is one piece of my code that stands
out as being totally stupid and unneccesary. I scan the polygons for edges
using Bresenhams line algorithm, which, as you probably know, works a bit
like this:
m = (x2-x1)/(y2-y1)
Then you just add m to x to get the line (and through that, the edge).
Something like that anyway. Needless to say this leads to some fractions,
or floating points. And that's the problem. Currently I'm shifting the registers
PC-style to get the fractions, but this seems more than a little stupid
when I've got an FPU in this lovely machine.
Only problem is that I can't get the bloody thing to work (or Macsbug is
having me on).
Could you please (briefly, of cource) give me some sort of crash course
in this FPU-buisness? I'm sorry to say that the PowerFantasm manual hasn't
been too helpfull, and the whole thing is slowly driving me nuts. It's one
of those things where you know your code could be a lot faster, but you're
afraid to try it because it might mess the whole thing up. So what do I
do? Feed the coordinates too some FPU-registers? How do you convert them
back to integers? Is there no way to save FPU-results in registers? Is Macsbug
right when my numbers looks weird in the FPU-registers (sometimes it just
writes NAN, or something)? I have the nagging suspicion that I'm missing
out on one of the most powerfull features on my Mac. Please help.
BTW, I hope this reaches you okay. I've just got my own private line to
the internet, and I'm not sure everything works yet. Needless to say it's
a lot faster than the pentiums we use at school.
Allan
Date: Mon, 31 Mar 1997 20:36:57 -0500
From: Stuart Ball <lightsoft@compuserve.com>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Fantasm/PowerFantasm update to 4.1.8.
For immediate release. Dated 31st Mar. 1997.
Both Fantasm and PowerFantasm have been updated to version 4.1.8. The updates are free and available on our WWW pages.
Details of update:
On some machines, and with some third party interface enhancement utilities,
the applications may crash after using the scroll bars. These updates correct
the problem.
Fantasm and PowerFantasm are assembly language development systems for MacOS based computers from Lightsoft.
Contact info:
email: lighsoft@zedworld.demon.co.uk
www: http://www.tau.it/lightsoft/index.html
Date: Mon, 7 Apr 1997 19:51:03 -0400 (EDT)
From: Figaro Tea <humphret@lurch.winthrop.edu>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: New Way To Program?
I've been thinking again <uh oh> and I thought I'd share what I've been thinking about.
With all the talk about new OSs and such I've been thinking what a pain it's got to be to support the multiple OSs out there. I know it's done now like when Blizzard recompiles Warcraft to run on the Mac--heck, now that I think about it, what I'm going to say might be null and worthless since it might actually already be implemented; but I think I'll say it anyway:) Anyway, simply recompiling your program won't necessarily work when you port from system to system, because the APIs are going to be different. For instance, I don't know how you make windows in Windows!?! but we all know you'd have to use GetNewCWindow(), or some other similar call for the Mac; now how are you going to recompile that for Windows?
It's possible the compiler might recognize that GetNewCWindow() is a Mac function and substitute in the appropriate Windows function...but I doubt that's the case. Even if it were possible it would mean more upgrades and such for a compiler to recognize all the function calls. And now we get to my idea:
Basically, my idea is to write programs in a do-it-yourself fashion and a use-the-API mode. Back when hard-core power programmers wrote code for windowless computers, like the Apple II and DOS machines, they had to create windows themselves since the acronym API didn't even exist. If you wanted to port a program from an Apple II to a PC you really just recompiled since practically *all* the code was yours and wasn't a part of the Apple II--I say practically because there was still some OS specific functions. Nowadays, if you want a window you just call GetNewCWindow() and the OS, whatever it may be, will handle it for you; of course you just can't recompile this when you migrate to a PC.
So why not use an application specific routine in place of *every* OS routine. Instead of using GetNewCWindow(), you could use something like CreateWindow(); you could pass this function, say the number 1, to let it know to draw a specific kind of window. If you were writing for the Mac, the actual code itself might be nothing more GetNewCWindow(), the function would be smart enough to know that the number 1 meant use a resource and that the resource was resource ID 128. For Windows the code would be whatever, if Windows doesn't support resource types, or even premade windows, then you could call the Windows function that creates windows and pass it the same information that would make the window look like the Mac window. You could even write a similar function for DOS, of course you would have to draw ASCII characters on the screen to get the window to show up, but you would have a window on the screen.
The function itself, and every other application-OS interface function, would be in their own files. This way when you port it to a PC you really just recompile the main part of your program, the part that actually does stuff, and you rewrite the application-OS functions. You would end up with OS plugs: you could just plug in the Mac plug to get working MacOS stuff, and the Windows plug to get <cough> working Windows code--you would still have to recompile every thing though. The benefit is synonymous to using constants instead of hard-coded numbers in your programs: you want to change the Monster Damage value to 10 from 100, you just change it in one place and the rest of the code reflects the change. Similarly, you want to write code for Windows, *just* change the application-OS functions, and the rest of the code reflexts the change.
Essentially, you separate the OS code from the application code.
The actual application code you would use, CreateWindow() in the example above, would depend totally on your application, and how to interpret the values sent to it would depend totally on you. It would be really neat if there was a standard operating system, but with monopoly-minded Microsoft runnin' around the chances of that are slim. Until then, I think my idea can do a lot to help port code from system to system.
--- Comments, Suggestions, Dialog Boxes... ---
..._Tim_...
--=[Live your life in the present, history will make itself in the future.]=--
http://www.winthrop.edu/~humphret
zzhumphreyt@winthrop.edu
Date: Mon, 7 Apr 1997 21:58:02 -0400
From: Stuart Ball <lightsoft@compuserve.com>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: re:New way to Program?
Tim wrote:
--lots on abstraction--
Some people will find this funny, because I've been moaning quite a lot
this week about exactly this system :-)
Hi Tim,
Sorry to sound a bit square, but you were right in your opening paragraph.
You'll find that most largish programs follow exactly that rule - Doom, MSWord and our very own Anvil run in their own little OS sitting on top of the host OS. (As far as possible anyway; for example producing a window that doesn't look very Macish can be a bad idea).
Why? For exactly the reasons you point out. When the OS changes (sounds familiar?), or you want to move platforms, rather than a complete rewrite just change the i/f boxes and away you go (that's the theory anyway...).
On the downside, writing your own routines is hard work and seems not very productive at the time as there are perfectly good OS calls available plus there's bound to be a minor speed penalty. The upside is as suggested in your mail. The most helpful technique (IMO) for O.S. abstraction is modularisation and merged projects which you can't do easily with fant4 but can with Anvil.
Things I'd guess you might want to abstract include:
any file i/o (You can take this to extremes if you like, as DOS boxes don't
have resource forks on their files - don't ask me why - seems like a brilliant
idea to me!)
any sound i/o
user input
printing
maybe task control (scheduling, preempting tasks (you can do this with sys7
contrary to popular belief with a timer task which is what the thread manager
uses I'd guess) etc.)
task messaging and locks (nightmare, specially with "pure" tasks
(as they should be :-))).
network i/o and networked tasks (i.e. remote parallel processing).
etc.
So, I guess if you take that little lot, what you end up with is you're own mini-OS sitting on top of the real O.S.
As ever, in the real world it isn't as easy as that, but it goes a long way to helping.
There are cross platform tools available - for example Microsofts VC++ which has a Mac/Windoze (spit) translation library. It costs lots and produces slug code, but is used a fair amount in the multimedia business.
Nice discussion point. Anybody have any experiences to share with us on this?
Stu.
Date: Mon, 7 Apr 1997 19:27:25 -0800
From: Kevin Avila <kevin@cache-computing.com>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re: New Way To Program?
Well Tim. I've been thinking about that as well while developing both of my OS's. The best thing that I found to do, and we spoke aboout this earlier, is to use Macro's. I'm not sure of the exact syntax of Fantasm macro's, but in my development envirment that I use (that in turn uses PF to compile) a simple window creating code would look like this:
let OS="Macintosh"
blah..blah..my code
FN CreateWindow(@parms) <-calls macro below
MyMacro:
choose !OS
case: Macintosh
GetNewCWindow(@parms) <- macintosh function
case: Windows 3.1
WindowsWindow(@parms) <-windows function
end !OS
So what this does is when you compile your program it sees that 'CreateWindow' is a macro and then looks at that macro. The macro sees that 'OS' is set to 'Macintosh' so it in theory converts 'CreateWindow' to 'GetNewCWindow' and so on. Macro's are a blessing. I use them when and where ever I can.
----------------------------------------
Kevin Avila http://www.cache-computing.com
kevin@cache-computing.com
Date: Tue, 8 Apr 1997 00:55:54 -0400 (EDT)
From: Figaro Tea <humphret@lurch.winthrop.edu>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: RE(2): New way to Program?
On Mon, 7 Apr 1997, Stuart Ball wrote:
> Hi Tim,
> Sorry to sound a bit square, but you were right in your opening paragraph.
Because I've deleted my original post I've forgotten what my first
paragraph was:) But if I think I know what you're talking about, getting
excited about something that's already been done, then that's alright.
That's one of the problems this world has, people don't talk about stuff
because they think they may sound stupid, like me:) Who knows, there's
probably someone else who was thinking what I was thinking but just
didn't speak up...
> When the OS changes (sounds familiar?)
This is the very thing that prompted me to think about OS abstraction
in
the first place! The Macintosh has so much potential, not only for
market share, but for learning too. Where else can you get a platform
that has two radically different OSs, and two very different processors
both specifically for it; perfect breeding ground for OS abstraction
techniques, don't you think.
> On the downside, writing your own routines is hard work and seems
not very
> productive at the time as there are perfectly good OS calls available
plus
> there's bound to be a minor speed penalty.
You wouldn't be writing your own OS, it's like Kevin said in his email:
you can use macroses to decide which OS call to use. I have OS
abstraction envisioned similar to language. When you think you, well,
think. You think regardless of what language you speak: Kevin and I were
both thinking of OS abstraction, I don't know if he's British but if he
is, he more or less speaks a different english than my American; point
is, is that we thought the same thing regardless of how we expressed it.
This is the same thing with OS abstraction, your program does what it
does regardless of whether it's expressed on a Mac or a PC: OS
abstraction allows the program, the thought, to be independent of
expression. BTW, I'm not high on anything:)
> So, I guess if you take that little lot, what you end up with is
you're own
> mini-OS sitting on top of the real O.S.
Pretty much. The only difference is that you let Apple or Microsoft
implement it:)
> As ever, in the real world it isn't as easy as that, but it goes
a long way
> to helping.
Maybe because I'm young and naive, but I don't think it has to be that
hard. True, there would be some difficulty in actually doing it versus
just talking about it, but it could be done.
..._Tim_...
--=[Live your life in the present, history will make itself in the future.]=--
http://www.winthrop.edu/~humphret
zzhumphreyt@winthrop.edu
Date: Tue, 8 Apr 1997 10:33:10 -0400
From: Stuart Ball <lightsoft@compuserve.com>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: re(3): New way to program?
Tim wrote:
>That's one of the problems this world has, people don't talk about stuff
>because they think they may sound stupid, like me:) Who knows, there's
>probably someone else who was thinking what I was thinking but just
>didn't speak up...
I agree wholeheartedly.
Yes there is a difference between abstracting via run time code and via
compile time macros etc.
Being able to write a program with no regard for the language is nirvana.
It can't happen however (theoretically speaking) because the simple act
of
converting a thought into a command (or set of commands) naturally
specifies regard for some kind of language.
Were there just one language which handled all circumstances, the world
would be a sad place.
Indeed, this cannot happen as it is [generally accepted to be] impossible
to quantify all possible circumstances. Even just trying would result in
a
program so large it would be unfeasable and run like a sloth on valium on
Christmas afternoon.
Stu.
Date: Tue, 8 Apr 1997 11:35:26 -0400 (EDT)
From: Figaro Tea <humphret@lurch.winthrop.edu>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re: re(3): New way to program?
On Tue, 8 Apr 1997, Stuart Ball wrote:
> Being able to write a program with no regard for the language is
nirvana.
> It can't happen however (theoretically speaking) because the simple
act of
> converting a thought into a command (or set of commands) naturally
> specifies regard for some kind of language.
Not really, you can tell a kid to leave you alone by just looking at
him
in a certain way; I know this isn't quite the same as what was said above,
but it still communicates without using language. I've heard that two
people who are very close to each other can communicate without language,
sorta like telepathy.
> Were there just one language which handled all circumstances, the
world
> would be a sad place.
In the real world standards are more or less a bad thing, imagine how
drab looking a school is that has uniforms instead of letting the kids
wear what they want. But in the technology world standards are a good
thing. Back when railroads were first being introduced each company
decided on their own railway implementation: spacing of the track, number
of rivets, etc... You couldn't take a train to a certain part of the
country if another company serviced that part, the track size may have
been different. Only when each company was told to do things the same way
could riding the rails be hasslefree.
> Indeed, this cannot happen as it is [generally accepted to be] impossible
> to quantify all possible circumstances. Even just trying would result
in a
> program so large it would be unfeasable and run like a sloth on valium
on
> Christmas afternoon.
You don't have to implement every possibility, just the ones you need.
For instance, I'm not using sound in any of my programs so I don't have
to implement Sound Manager routines at all. If I did need sound, and
lets say the Mac couldn't do it, then the sound code that I would write
wouldn't do anything; even though the rest of the program would be trying
to use sound--it might try to adjust the volume or something, even though
nothing would actuallly happen. When the program was implemented on a
system that did have sound, I could rewrite the sound code only and the
rest of the program naturally gets a facelift, errr, an earlift. It's
like I can use standard Menu Manager routines to draw my menus and get
standard looking menus, but when I install Kaleidoscope my menus look
entirely different even though I don't change anything in my program.
There would be some difficulty in identifying which routines should be
handled by the OS and by your program. My simple answer is that they all
would be implemented by your program. It's just that you'll notice that
the Mac has sound manager routines so you'll cheat and use their's; you
won't directly implement them though, you'd just make your sound code
drastically shorter and simpler. Programs written in this fashion would
be OS-less, an OS would be used merely to enhance the program; similar to
Kaleidoscope.
..._Tim_...
--=[Live your life in the present, history will make itself in the future.]=--
http://www.winthrop.edu/~humphret
zzhumphreyt@winthrop.edu
Date: Tue, 08 Apr 1997 20:53:48 +0200
From: Allan Lund Jensen <maccoder@post6.tele.dk>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re: New wau to program?
Figaro Tea wrote:
>
> On Tue, 8 Apr 1997, Stuart Ball wrote:
>
> > Being able to write a program with no regard for the language
is nirvana.
> > It can't happen however (theoretically speaking) because the simple
act of
> > converting a thought into a command (or set of commands) naturally
> > specifies regard for some kind of language.
>
> Not really, you can tell a kid to leave you alone by just looking at
him
> in a certain way; I know this isn't quite the same as what was said
above,
> but it still communicates without using language. I've heard that two
> people who are very close to each other can communicate without language,
> sorta like telepathy.
>
> > Were there just one language which handled all circumstances,
the world
> > would be a sad place.
>
> In the real world standards are more or less a bad thing, imagine how
> drab looking a school is that has uniforms instead of letting the kids
> wear what they want. But in the technology world standards are a good
> thing. Back when railroads were first being introduced each company
> decided on their own railway implementation: spacing of the track,
number
> of rivets, etc... You couldn't take a train to a certain part of the
> country if another company serviced that part, the track size may have
> been different. Only when each company was told to do things the same
way
> could riding the rails be hasslefree.
>
I think it's only in theory that technology world standards are a good
thing. The one who's got the patent is the one makes all the money and
decides how the OS should look like (just look at Microsoft).
Although it would be a neat thing if the same code worked on PC's as
well as Macs, I must say it's a prospect I don't look forward to at all.
Part of owning a Mac (or any other computer other than a PC) is usually
about being different. Different OS' is natures way of making certain
that there are plenty of jobs to programmers ;)
Allan
Date: Tue, 8 Apr 1997 20:27:59 +0100
From: Rob Probin <rob@zedworld.demon.co.uk>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re: re(3): New way to program?
> People wrote:
> ... various stuff about abstracting the Operating System, including
> using macros...
>
It is an idea that ALL programmers want. How about being able to port
you
newest program just be re-compiling into MkLinux (wow ... Rob instantly
uses MkLinux for development). And being able to run the same things on
friends PC's. And being able to run it on other PowerPC boxes, or Intel
boxes... or.... forever. Fantastic.
I have two problems with it:
(a) assuming it was more than 90% efficient means all O.S. manufacturers
would be DEAD against it and would do everything in their power to kill
it.
High level languages effectively removed (nearly) the need for a particular
processor - and the money shifted to Operating Systems. This would do the
same for Operating Systems. (The technology does exist but it's less than
90% efficient*).
(b) The other BIG problem is not just the operating system calls, but
the
data structures related to the operating systems. This forms a big
problems. The solutions are (a) translate data structures (slow) (b)
provide accessor routines that do the functions that are otherwise
(sometimes) performed on data (long time to identify such).
Generally I would LOVE such a technology. However, a lot of companies
(including our Apple) really base their money on 'Systems isolation'.
The figure of 90% is 'high' because this is in addition to the efficiency
of the compiler - ranging between 40% to 95% for a good compiler (I quote
this range because all compilers are sometimes very good, and sometimes
very bad).
Rob
* Compile time example VC++.
* Run time example maybe Java(?).
Date: Tue, 8 Apr 1997 23:26:04 +0100
From: Rob Probin <rob@zedworld.demon.co.uk>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re: re(3): New way to program?
> Rob wrote:
>* Run time example maybe Java(?).
Stu and I have discussed some of the ideas we have been talking about
in
this discussion, and I thought I would share some of them here.
C (or any other high-level language) is abstraction layer. For the ease
of
not knowing the assembler language of the particular processor (there are
other advatages, but I'll ignore those for clarity) you lose speed and
control.
An operating system is an abstraction layer from the hardware itself.
The
MacOS has protected all of us - and made it easier for Apple Hardware
engineers to use lots of different chips to make their computers. It also
provides features of course (like GUI and multitasking facilities) but
primarily its task (and the original reason) is to isolate the hardware.
Not everyone want to write a disk drive driver (especially since of all
the
different controllers... every tried recognising a 'VGA' display
controller?).
Effectively this is Speed and Control vs. abstraction from hardware (either
processor or environment). Most Fantasm programmers isolate themselves from
the hardware by using the MacOS but still want the speed and control that
assembler language provides for them.
Many programs that are ported from one system to another use their own
abstraction layer. Their _own_ abstraction layer means higher efficency
(since they know the target problem).
Although languages HAVE standardised, for some reason API's have not
standardised - their is no standardisation body to do this in my knowledge.
Why? I really have no idea. (In fact I'm not sure I really understand why
language standardisation body's have sprung up, or why compiler companies
follow them).
I use the MKLinux environment as a example - the Mach Kernal is the 'real'
operating enviroment, the Linux core is the API and XWindows is the 'front
end'. This is actually a very poor example because XWindow contains
graphical API calls, and the Linux core contains API functions, etc,etc.
From my point of view, the 'front end' - which is what makes it LOOK
and
FEEL different - is NOT the API (the application programming interface).
I
understand Allan's comments - but I also think that it's a real bitch
having to rewrite major chunks of operating system code.
Stu has placed the arguement that the API does however effect the front-end
and the Operating environment (like the insides). O.S. manufacturers want
to expand it as they like, and machines are not powerful enough to 'float'
a seperate API from the core functions that the operating system has to
carry out.
If seperate API's didn't exist that would mean applications could be
compiled across from one platform to another with ease. We would probably
have a situation like in the unix world whether people would supply their
source code since they would not know which processor it was running on.
This is something which something which Microsoft will resist - it gives
them much less security - Bill Gates' marketing stratagy is to provide free
proprietry techology to capture the market, then make them pay for it. They
have 100% of the market (or nearly) and they own that market share because
they own the technology.
Looking from the other end of the telescope, its strange why Microsoft
haven't ported Windows to Mac Clones. I believe Microsoft's main OS has
quite a bit of pure Intel code. If it was all high-level code why wouldn't
they want to put it on all processors? Why wouldn't they make the jump to
RISC, another processor architechture? (I know it's not that simple -
but...) I know Windows NT does run on PowerPC machines. Its strange that
they have stopped it. Why are they protecting Intel's Silicon? Probably
to
try to protect their own market.
Which makes me think it would be good to get MacOS (any form!) on Intel
processors. (Even though the h/w is terrible - Wot no sound as
standard????!!!).
Another thing limiting Microsoft from jumping processors in the operating
system stakes is because they don't make the BOXES (and possibly haven't
got the guts to jump - unlike Apple - as a sideline one of the BIGGEST,
smoothest stunts of the computer age was the processor jump from CISC to
RISC).
To go back on topic... brings me back to how Java achieves its operating
system independence. It does it by creating the model of a virtual Java
machine, which is standardised. Effect: Slow!
Rob
Date: Tue, 8 Apr 1997 19:44:00 -0400 (EDT)
From: Figaro Tea <humphret@lurch.winthrop.edu>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re(4): New way to program?
On Tue, 8 Apr 1997, Rob Probin wrote:
> It is an idea that ALL programmers want. How about being able to
port you
> newest program just be re-compiling into MkLinux (wow ... Rob instantly
> uses MkLinux for development). And being able to run the same things
on
> friends PC's. And being able to run it on other PowerPC boxes, or Intel
> boxes... or.... forever. Fantastic.
>
>
>
> I have two problems with it:
>
> (a) assuming it was more than 90% efficient means all O.S. manufacturers
> would be DEAD against it and would do everything in their power to
kill it.
> High level languages effectively removed (nearly) the need for a particular
> processor - and the money shifted to Operating Systems. This would
do the
> same for Operating Systems. (The technology does exist but it's less
than
> 90% efficient*).
As more and more OSs get developed and more and more software works on
a very limited set of computers you can expect that either one or two
things will happen (a) One company gets a standard operating system that
everyone writes for or, (b) Programmers develop ways to write code that
works on all platforms. The first is pretty damn near to occurring as
Microsoft has a de facto standard with Windows. Since a lot of people
don't want Microsoft to get a standard, and as Stu said earlier, lack of
variety would be detrimental; you can expect the second option to gain a
lot of favor. There wouldn't be any new technology involved in OS
abstraction, just a new way of programming; new technology may come to
help implement it, but by itself it isn't new technology.
As far as high-level languages making processor inovation more or less
mute: change is inevitable, and the same thing will happen to OSs. The
same way that there are certain processor instructions that are rarely,
if
ever, used, the same way there will be certain OS functions that won't
get used in favor of the more compatible functions. Of course companies
will resist change, but it will occur, end users will see to that.
> (b) The other BIG problem is not just the operating system calls,
but the
> data structures related to the operating systems. This forms a big
> problems. The solutions are (a) translate data structures (slow) (b)
> provide accessor routines that do the functions that are otherwise
> (sometimes) performed on data (long time to identify such).
The second option you mentioned is what I've been talking about all
along: instead of accessing the OS functions directly you have
intermediate functions that access the OS. Apple has already done
something similar to this with their plug-and-play. When you draw to the
screen you use QuickDraw calls and you don't directly plot to the screen,
this way your code works on all different types of hardware. Of course
there is a speed gain by not using QuickDraw, but there's also the loss
of compatibility. This is the same thing that will happen with OS
abstraction: you'll lose some speed and flexibility, but you'll gain
compatibility with other platforms.
> Generally I would LOVE such a technology. However, a lot of companies
> (including our Apple) really base their money on 'Systems isolation'.
Unfortunately, Apple, and everybody else, will have to find a new way
to
make money. The same way that the railroad companies I mentioned in my
previous post had to give up their inovations in sack of compatibility,
the same way computer companies will have to change.
..._Tim_...
--=[Live your life in the present, history will make itself in the future.]=--
http://www.winthrop.edu/~humphret
zzhumphreyt@winthrop.edu
Date: Tue, 8 Apr 1997 20:28:26 -0400 (EDT)
From: Figaro Tea <humphret@lurch.winthrop.edu>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re(5): New way to program?
On Tue, 8 Apr 1997, Rob Probin wrote:
> I understand Allan's comments - but I also think that it's a real
bitch
> having to rewrite major chunks of operating system code.
I don't know where rewriting chunks of the OS came from, but this wouldn't
have to be done anyway; at least no more rewriting that has to be done to
port code between platforms today. I honestly think you guys are making
this more difficult than it really is, or has to be. As Kevin mentioned
in a previous post you could simply use a macro to decide which code to
include for a particular OS. Stu, or Rob, one of you guys mentioned in
the Fantasm documentation that you set a flag to assemble the Fantasm
demo and the full thing, this is the same thing except the objective is
a
different OS. The caveat I think you guys are targetting is what if the
OS you're writing to doesn't support something that's done in one line in
the current OS. Well, you write the code to implement it. If at some
point you decide that it's too much then you won't port it; some PC
companies think it's worth it and port stuff over to the Mac. What I'm
talking about is; at its worst, the same thing that's done now involving
porting; and at its best, the best thing to come along since sliced bread.
> To go back on topic... brings me back to how Java achieves its operating
> system independence. It does it by creating the model of a virtual
Java
> machine, which is standardised. Effect: Slow!
What I'm talking about won't be as system independent as Java, since
you'd
have to rewrite your code to interface with the target OS--which is what
is done now with porting. The benefits of what I'm talking about would be
synonymous to using constants in your programs: you could just change
things in one place and not have to search your code to find all the
little things that are OS specific.
..._Tim_...
--=[Live your life in the present, history will make itself in the future.]=--
http://www.winthrop.edu/~humphret
zzhumphreyt@winthrop.edu