Date: Mon, 21 Apr 1997 00:30:54 +0200
From: Allan Lund Jensen <maccoder@post6.tele.dk>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re: The Joy of Assembler
James Hague wrote:
> Cool optimizations don't usually come from rewriting little routines
in
> assembly though, but from rewriting big, huge chunks of code. Dodging
> the subroutine entry/exit code on the PPC can be a big deal.
(I thought it was bit too early to but this thread to rest (especially
since we know we're right ;))
As I understand it rewriting little routines in assembler *does* make
a
difference. If you take a look at some of the 3d-engines you can find on
the net (PC ones) you will nearly always find a bit of assembler in
them: the screen writing routine. If you haven't seen it yourself, you
should take a look. You have no idea how much time these guys spend
shaving clock-cycles of a pixel-plotting routine.
So obviously it still pays to include some assembler. I would think the
same applied for Mac.
This is something that is never discussed on mac-pages or in
mac-newsgroups. Why is that?
I know I'm slightly gullible, but I used to assume that Mac-programmers
naturally did the same. I still assume *some* assembler goes into
Marathon at some point. If not, I must admit I'll be
surprised/disappointed.
There's nothing mystic or 'ugly' about using assembler. It's a natural
and obvious way to make your program faster (I made that sound like a
commercial for shampoo, didn't I?).
The point I'm making (yes, there is one) is, that it's annoying to know
you've got the better computer with the faster processor, and still see
fairly simple games slow down on a 120Mhz PPC. It ought not to happen (I
could give you examples, but I've discovered you never know who's on
this list-server). Especially since the same thing wouldn't happen on a
slower Pentium (bet that sentence will haunt me), because they usually
bother to use some assembler.
Granted C-compilers are getting better and better, but I'll still bet
that a assembler-written screen-splatter/pixel-plotter will beat a
c-version any day of the week.
It'll be interesting to see if any of the Fantasm-users will make a game
(hey, I might even give it a try this summer :). That might convince
some Mac-programmers that assembler can be used with better results than
pure C (Bumbler was neat).
So to sum up, there *is* a joy about assembler, too bad so few wants to
experience it ... maybe if we explained it to them at gunpoint?
Rob wrote:
> In the end, all the reasons for high level languages (reliablility,
> maintainablility, etc, etc) boil down to one thing: FASTER CODE
> DEVELOPMENT. Thats all. And when execution speed is not an issue, business
> takes the easier, cost effective option. (What they often miss is the
> actual *quality* of the program is not improved by doing things faster...)
>
Although I'm very much in favour of Sprockets (in theory, anyway) I was
surprised to read that Actua-Soccer from Gremlin wouldn't have made it
to the Mac if it wasn't for the Rave-sprocket. Gremlin said something
like "it wouldn't be possible to make Actua without sprockets".
What
they probably should have said, was: we couldn't be bothered to make it
ourselves, because it would take too long. Actua-Soccer didn't exactly
'fly' on my machine, perhaps they should have bothered? Yep, faster code
development certainly is what's on some peoples minds.
BTW, I'm not trying to start a big sprocket-debate (although I'd be more
than willing to write a few words about them ;)
(For example, could someone please convince me that sprockets are of any
use to assembler-programmers? Besides Net-sprocket...)
Allan (I have way too much spare time, don't I?)
P.S. ...erm, after re-reading the above it occured to me I might look
like a bit of a PC-advocate. Rest assured I'm not. After spending these
last few weeks doing windows-programming in C++, I'm rapidly becoming
aware of the true meaning of pain. One of these days Bill Gates will
admit he was just kidding when he released Windows...
Date: Sun, 20 Apr 1997 20:28:34 -0400
From: Stuart Ball <lightsoft@compuserve.com>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re: The joy of assembler (Rev2)
Allan wrote:
>As I understand it rewriting little routines in assembler *does* make
a
>difference.
I'd go with you on this one Allan (and with all due respect to James).
You are spot on about the screen splat.
Hard facts (this is on a 75Mhz 601):
Draw Sprocket~=20 to 25 Megabytes/second (non-sync'd).
Custom FPU splat = 44 Megabytes/second using doubles, 37 with singles.
The FPU splat has been refined some four or five times to achieve that rate
(it started at 27 MB/sec). Plus, by using the FPU for the moving you can
(carefully) intermingle integer instructions to do some other useful
processing at the same time. The code is tight.
I would have great, great difficulty coercing a compiler to produce such
code.
Compiler optimisiations in this case would probably compound the problem.
OK, now granted you can get round the limitations of a slow splat with
delta
encoding (i.e. just drawing the changes rather than splatting the whole
screen). This is something of a fine art. A simple technique is zoning,
or breaking the
2d plane up into rectangles, and monitoring them for changes; then just
splat
the zones that have changed. This can get rather complex and is a balancing
act between the number of zones and the amount of calculation you are willing
to perform. The monitoring can be done with a calculation or lookup to
translate real coords (normally output from the perspective print routine
as a
rectangle, or hey, even a polygon) into affected zone(s) to form the splat
list.
This can offer very real performance improvements over a simple splat.
Even
just two zones (top half and bottom half) will provide performance gains.
>The point I'm making (yes, there is one) is, that it's annoying to
know
>you've got the better computer with the faster processor, and still
see
>fairly simple games slow down on a 120Mhz PPC.
You've got my vote on that one.
>BTW, I'm not trying to start a big sprocket-debate (although I'd
be more
>than willing to write a few words about them ;)
>(For example, could someone please convince me that sprockets are of
any
>use to assembler-programmers? Besides Net-sprocket...)
I'm sure sprockets have their place; for example SoundSprocket allows you
to
do positioning linked to the "camera" out of rave, which is what
you'd expect
in any half decent fp3d effort.
But until they speed them up somewhat they're not something I'd actually
use.
They may be useful for prototyping?
They're great for compatibility, BUT at the expense of performanace.
The way I see it on a Mac with no page swapping, if I call DrawSprocket
to
splat a screen it goes (I may be wrong on this one, if so, please correct
me):
my_prog passes lots of parameters to drawsprocket.
drawsprocket passes lots of parameters to copybits.
copybits does lots of checking.
copybits calls blockmove.
Ick!
Back to the grind,
Stu.
Date: Sun, 20 Apr 1997 21:50:43 -0700
From: Kevin Avila <kevin@cache-computing.com>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re: The joy of assembler (Rev2)
>>BTW, I'm not trying to start a big sprocket-debate (although
I'd be more
>>than willing to write a few words about them ;)
>>(For example, could someone please convince me that sprockets are
of any
>>use to assembler-programmers? Besides Net-sprocket...)
>I'm sure sprockets have their place; for example SoundSprocket allows
you to
>do positioning linked to the "camera" out of rave, which is
what you'd expect
>in any half decent fp3d effort.
>But until they speed them up somewhat they're not something I'd actually
use.
I feel the same way. So about a month ago I started at little prject
if
you will just collecting cool draw/sound routines and organizing them. I
call it IDNYSS or "I Don't Need Your Stinking Sprokets". So if
you have any
cool little code snippets, please send them to me. :)
----------------------------------------
Kevin Avila http://www.cache-computing.com
kevin@cache-computing.com
Date: Mon, 21 Apr 1997 09:45:13 -0400
From: Ajay Nath <AjayNath@compuserve.com>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re:(2) Computer Problem
Figaro Tea wrote:
>>Is there a way to trim down the System to get just the stuff you
need;
i.e. what files are essential for bootup?
<<
use the minimal boot disk that came with your mac as a start...i examined
the one that came with my powerbook & saw that the way it worked was
to
have a lot of compressed system resources/code...so when it booted it just
uncompressed the code into memory & trundled along
>> Cool optimizations don't usually come from rewriting little
routines in
>> assembly though, but from rewriting big, huge chunks of code.
Dodging
>> the subroutine entry/exit code on the PPC can be a big deal.
>
>As I understand it rewriting little routines in assembler *does* make
a
>difference. If you take a look at some of the 3d-engines you can find
on
>the net (PC ones) you will nearly always find a bit of assembler in
>them: the screen writing routine. If you haven't seen it yourself, you
>should take a look. You have no idea how much time these guys spend
>shaving clock-cycles of a pixel-plotting routine.
True. Weird CPU + Bad Compiler + Code that takes 90% of the total
execution time = good place to hand code :-)
I guess my original point was that writing snippets of assembly code
to
replace C functions is one thing. Sometimes you win, sometimes you
don't. This is the case that compiler writers usually worry about, and
why they often argue that you can't beat them by hand coding. Writing a
big chunk of code, or library, or whole program, in assembly changes the
rules completely. You can beat even the best compilers by tremendous
amounts (by keeping a set of registers valid across a series of function
calls, for example).
James
Date: Tue, 22 Apr 1997 23:46:57 -0400
From: Ajay Nath <AjayNath@compuserve.com>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re: The Joy of Assembler
Jame said:
<<
I guess my original point was that writing snippets of assembly code to
replace C functions is one thing. Sometimes you win, sometimes you
don't.
>>
IMHO & from my experience the BIGGEST gains I've seen have come from
changing from one algorithm to another & the gains from recoding portions
in asm are smaller.
Date: Tue, 22 Apr 97 21:14:15 -0700
From: James Hague <jhague@dadgum.com>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re: The Joy of Assembler
>IMHO & from my experience the BIGGEST gains I've seen have come
from
>changing from one algorithm to another & the gains from recoding
portions
>in asm are smaller.
Well, I really put my foot in my mouth with my original comments! I
should have said "all things being equal" and "assuming a
programmer
who's read the requisite Knuth and Wirth, etc."
James
Hi everybody
Things has seemingly been very quiet on the list-server. Or have they?
(start scary music).
It all started with the excellent program Godots World, and has since
changed into a debate about: Tims idea for a new programming language,
porting programs to another platform and the fact that one day there
will only be one platform to write for.
You see, Tim (Figaro Tea) and I (Allan) are very nearly in total
disagreement about this. And after the last mail, which was number 5
from each, we decided it could be interesting to hear other peoples
point of view.
Now, I cant speak for Tim, so Ill just share my thoughts about this
and hope Tim will state his case against, later.
I realise this is the sort of discussion that could take forever, but
since its a key-issue with developers (especially assembler), the
list-server just might be the right place to have this debate.
The case for the defence, milords:
1) Porting programs. Especially from Mac to Windows.
My feeling about this is as simple as this: if every Mac-program was
also available for PC, then why not just buy a PC.
When Joe Public walks into a store and says: I need to use
XXXSpreadsheet. I heard its only available for Mac, so I suppose Ill
buy one of those too. To this the salesman can say: Well,
XXXSpreadsheet has just been ported to Windows. Why not buy a PC
instead, so you can play Quake as well. The customer looks
hesitant...Salesman: And Pcs are cheaper,too. And thats all Joe
needs to hear, so he buys a PC.
This is a very simplified version of the facts. But its not so far from
the truth.
Nintendo knows the truth of this. The day you see Mario outside a
Nintendo machine, is the day the devil will go to work in a snow-plow.
(Yes, I know some *educational* Mario-programs have been ported, but not
*real* Mario-games).
As I said to Tim, killer-applications sell computers.
Now, Im not a fanatic about this. I know some people are. Im sure
there are people who cursed Bungie for porting Marathon to PCs. I can
see the financial wisdom in porting. But I also see some dangers in it.
It seems that Mac-owners (friendly as they are), are spending a lot more
time porting things to PC than vice-versa. It also seems that Apple are
spending a lot more time developing things to Wintel than vice-versa. If
this continues then that great unified platform were heading towards
could very well be: windows.
Since this list-server is used primarily by assembler-programmers, I
would assume you have pretty solid views about porting. Since porting,
for you, would mean a complete rewrite of your programs.
2) One platform
Tim says this will soon happen.
I say it will never, ever happen. As I said Tim should be writing his
own answers soon, so let me tell you what I think.
People like to have a choice. No, they *need* to have a choice. Are you
a Pepsi-drinker, or a Coca Cola-drinker? Do you drive Mazda or Ford?
Burgerking or McDonalds? Imagine if the choice of computers would boil
down to: Do you want one, or not?
I see a lot more problems with one platform, than I see solutions.
Whos going to set this standard? If the american government was nervous
about the size of Microsoft at some point, then this new standard will
make them wet their pants.
If Microsoft, Apple and IBM were to make a new common standard, someone
would continue to make another. And people would, from time to time, use
this instead. As I said: we need the choice.
3) Tims programming language
Actually I think its a rather neat idea. I think it would be very
popular. I doubt it would be possible to make such a language at this
point. Machines still arent fast enough.
Closing arguments, your honour:
I said to Tim (and he agreed ;) ) that my point of view is ... well,
pretty childish. I hate Wintel. Bill Gates is not a very nice man.
There are newsgroups that deals entirely with that kind of thoughts.
But thats the computer-buisness for you. It *is* a war.
If we were better people one platform would have become a fact years
ago. Were not.
Star Trek is often portraied as the best possible future. You never see
Spock tell Scotty Could you please boot Softwindows, I need to run some
dianostics. There may be one platform in our future. I hope its a
long way away, and I sure as hell hope that platform wont be Windows
2007.
Tims views are the right views. On some level I agree with him 100%.
I just dont think the ideas are possible in the real world. No-one
agrees on how a OS should look. Or a computer. On the top of my head I
can mention at least 7 different OS. Each of them has core of
supporters that will damn near kill for it.
Now, I wouldnt kill for MacOS. But I *would* go as far as a small
papercut to avoid a future with Windows.
I have a lot more views on this, but I thought Id better cut it short.
I just think, that if PC-owners wants to know why we think Mac is so
great, they should have to buy one to find out.
So what do you people think? Is porting a good idea? Are we heading
towards one great platform? If so, arent we wasting our time with
assembly?
I hope Tim will be posting his case too, as hes got a lot of valid
points. Im entirely willing to be convinced of his case, but not just
yet...
If you are interested, I still have the bulk of correspondance between
Tim and me, and Ill mail it to you if the above didnt make any sense :)
Allan
>1) Porting programs. Especially from Mac to Windows.
Take two of the most ported games of all time: Doom and Mortal =
Kombat. They've been released for everything from the PC to the =
Jaguar to the Nintendo 64. Doom was originally written in C, =
with--as the Doom guys are fond of pointing out--only two assembly =
routines. Mortal Kombat was originally written in assembly. End of =
point.
>I=92m sure
>there are people who cursed Bungie for porting Marathon to PCs. I can
>see the financial wisdom in porting. But I also see some dangers in
it.
I agree. I would love to see some sales figures from Bungie on this
=
subject. Marathon is probably the all-time best-selling Mac game, =
but over on the PC it's "just another Doom clone." (Please don't
be =
offended, Marathon fans. By the time Marathon was released for the =
PC, there were several dozen such games already out for the PC.) I =
suspect it was lost in the fray.
James
Well, here's my point of view on the issues:
1) On Porting Programs
It should be done, period. With all the talk about how evil Windows and
how holy the Mac is, you kinda loss sight as to the purpose of using
computers: to get work done. When you have programs that work on one
system and not another then a real hassle develops. You can't share your
data with other people; I know computing is a personal experience and
all, but you need to correspond to other people and share what you're
doing. Nearly everytime I get a message from this list-serv my emailer
says that the message is in iso-something format and that not all
characters will be displayed correctly--a lot of times this means
apostrophies don't get displayed correctly. Imagine if weren't just
apostrophies, but nearly every letter that wasn't translated correctly:
I
wouldn't be able to read the posts because different character sets would
be used. Imagine this on a broader scale, like OSs, and you see a real
problem. I'm not going to get in real deep with the issue of which OS to
use, I just want to point out that while we're squabbling over which OS
is better, end users productivity is being stifled. The ultimate goal
should be that what I can do on a Mac, I can do on a Wintel. The same way
that I can send this message from a UNIX machine using Pine, or from a
Mac using Claris Emailer, or whatever; I have the choice to decide on
quality and not quantity, i.e. I don't *have* to use UNIX merely because
it's the only one that works correctly. In this respect, a standard will
develop, a standard in communication and not an OS; Allan, you remember
that
I said eventually OSs will be choosen based on how hassle-free they make
content delivery.
2) On One Platform
I may have stated in the correspondence with Allan that I think a single
OS/platform will emerge; but since I don't have the all of the previous
messages I can't be certain. I did, however, tell him that I don't think
a single OS will emerge; rather, a single way of communicating will
emerge. The Internet is changing the way things get done, as I said
above I can send this message using two different programs from two
different OSs, it doesn't matter because the programs speak the same
language. The same thing is going to happen, and is happening, with
every other aspect of computers. The day is going to come when it
doesn't matter what OS you use or what program you use because you can
communicate with every one else. OSs are going to be choosen on how
hassle-free they make things; already the Mac excels in this category.
However, for this to happen the programs to communicate have to exist on
all platforms. Allan's dogma of not porting to Windows will actually
decrease choice, because a person will have no choice but to buy a
certain system. If the same *kind* of program existed on both systems,
preferably the *same* program, then you have the choice between different
systems. I know many of you absolutely hate Windows, and for good
reason, but if we don't programs to it and other systems, then we'll be
just as bad as Bill Gates. In the long run it doesn't matter which OS is
written for as long as they're all written for.
If I could counter Allan's story about Joe and the salesman, I would
tell
Joe that he's getting what he's paying for: cheap crap. I would tell Joe
that PCs are initially cheaper but they'll cost you a hell of lot more
overall because they require constant attention. It's kind of like
choosing cars: do you choose the cheap fixer upper, or the slightly more
expensive reliable one?
3) On Program Modularization (aka My programming language)
From what Allan described it as you would think it's a new programming
language; but I'm going to go on the record and say, in all caps: IT
ISN'T A NEW PROGRAMMING LANGUAGE, BUT A NEW *WAY* TO PROGRAM! It most likely
isn't even new, just different. It would most resemble
object-oriented programming in that nearly every aspect of the program is
broken up into modules. Whenever you wanted to do something you would
call a subroutine to do it, you wouldn't just do it on the spot. There
would be a controlling logic that determines the subroutine calls, a
brain, and it would be responsible for running the program. As you can
probably tell from my brain analogy, I think modelling programs after
the human body would be the best way to go; the human body is incredibly
complex and yet it works amazingly efficiently, and scientists still can't
figure out everything about it. By having everything separated to do a
specific task and nothing else, you maintain a level of independence that
makes it possible to easily modify the program to do new tasks. As a
side benefit to this, it would also be quite easy to port to a different
OS, because all the OS calls are locked away in their respective cells.
As long as the cell communicates the same way on a Wintel the same way it
did on a Mac, the program will function normally; the cell may not even
use OS calls to get its work done, but it doesn't matter because it's
the input and output that matter.
I haven't sat down to really think this over, but that's the basics of
what I'm thinking about. Something you should note, is that you can do
this now in assembly, C++, or whatever; you don't need an entirely new
language to do this, just a new way of thinking about what it means to
create a program.
..._Tim_...
--=[Live your life in the present, history will make itself in the future.]=--
http://www.winthrop.edu/~humphret
zzhumphreyt@winthrop.edu
Hi,
Just to get my 10 cents in....
>It all started with the excellent program Godots World, and has since
>changed into a debate about: Tims idea for a new programming language,
>porting programs to another platform and the fact that one day there
>will only be one platform to write for.
>......
>1) Porting programs. Especially from Mac to Windows.
>....
> And thats all Joe
>needs to hear, so he buys a PC.
>....
>2) One platform
>I said to Tim (and he agreed ;) ) that my point of view is ... well,
>pretty childish. I hate Wintel. Bill Gates is not a very nice man.
I don't like PC's. I think they have been given a LOT of time and money
spent towards them, and they haven't given a lot back to the world. We
should stop flogging a dead horse and try for a better technology. E.G.
how
many operating systems have been written for it??? - and only NT4 comes
close!
However, are developers responsible for upholding a platform? I think
not.
In the end the only two things that really matter to people who release
(and you don't need both) - money and some recognition (that you
helped/gave something/are a brilliant programmer/whatever). There may be
a
very few who release things just because they want to help.
>If we were better people one platform would have become a fact years
>ago. Were not.
Better in what way? Perhaps we would have been foolish. I think we are
foolish with PREP for instance. It's like an updated PC. Just a processor
and standard chip set definition. Wheres the 'flexibility'. One platform
can only become any sort of reality when ANY processor/hardware/user
interface is supported. That way it isn't really one platform. UNIX comes
close, but falls on user interface.
>Take two of the most ported games of all time: Doom and Mortal Kombat.
>They've been released for everything from the PC to the Jaguar to the
Ninte=
ndo
>64. Doom was originally written in C, with--as the Doom guys are fond
of
>pointing out--only two assembly routines. Mortal Kombat was originally
>written
>in assembly. End of point.
>
Basically, you are saying, apart from a bit of money (and time - which
is
what costs the money), porting really isn't governed by whether that the
format the source is in.
Oh, and IMHO, porting high-level programs isn't what I'd call easy -
unles
you kill the differences of a machine (e.g. java).
>>I=92m sure
>>there are people who cursed Bungie for porting Marathon to PCs.
I can
>>see the financial wisdom in porting. But I also see some dangers
in it.
>
As I said before, there are two reasons to port money (company driven)
and
fame (individual driven).
>I agree. I would love to see some sales figures from Bungie on this
subject.
>Marathon is probably the all-time best-selling Mac game, but over on
the PC
>it's "just another Doom clone." (Please don't be offended,
Marathon fans. By
>the time Marathon was released for the PC, there were several dozen
such games
>already out for the PC.) I suspect it was lost in the fray.
Really very sad, since I would say Marathon is the best of it's type
yet.
(There tend to be two 'hits' in a particular style - the first and the best.
(e.g. for those of a Speccy background, in Isometric 3D - Knight Lore, and
Head over Heels. ).
Rob
Date: Sun, 27 Apr 1997 23:57:23 +0200
From: Allan Lund Jensen <maccoder@post6.tele.dk>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re: Porting and Platforms.
James Hague wrote:
> Take two of the most ported games of all time: Doom and Mortal
> Kombat. They've been released for everything from the PC to the
> Jaguar to the Nintendo 64. Doom was originally written in C, with-as
> the Doom guys are fond of pointing out--only two assembly routines.
> Mortal Kombat was originally written in assembly. End of point.
Yeah, but Doom and Mortal Kombat was two very special games. Both were
the first in their field. They wouldve been ported if they had been
written in russian.
But I can see your point, if you want to port something its certainly
possible. In Doom and Mortal Kombat the producers knew they were going
to get their money back. Heck, Doom could have afforded to suck on any
other platform than PCs, and theyd still end up with money in the bank.
Now Doom has run into other problems. Dont tell me you dont think
Christ, not again when you see another version of Doom.
> I agree. I would love to see some sales figures from Bungie on
this
> subject. Marathon is probably the all-time best-selling Mac game, but
> over on the PC it's "just another Doom clone." (Please don't
be
> offended, Marathon fans. By the time Marathon was released for the
> PC, there were several dozen such games already out for the PC.) I
> suspect it was lost in the fray.
Personally I think Bungie could have made more money if theyd stayed
exclusively on the Mac-platform. Bungie is certainly the most popular
game-developer on the Mac, and they know it. Some would probably buy
their games, just to support them. Same goes for Ambrosia. If you are
loyal to a platform, theres money in that too. There could be even more
money than in porting.
The PC-guys Ive talked to, thought that Marathon was nothing special.
I doubt it has been a huge success, so I dont think theyve actually
gained anything by porting it.
My point being, if youre porting a game/program you should make sure
that it will be just as popular on the other platform. You loose
something when you diverge into other platforms. Be sure its worth it.
Rob Probin wrote:
> I don't like PC's. I think they have been given a LOT of time and money
> spent towards them, and they haven't given a lot back to the world.
We
> should stop flogging a dead horse and try for a better technology.
E.G. how
> many operating systems have been written for it??? - and only NT4 comes
> close!
>
Okay, if were going to be honest about it: I dont like PCs either. I
dont like Windows. I dont like Bill Gates. I think its 70s
technology strapped to a rocket. But Im very careful not to be drawn
into those kind of arguments, because you can never win (although I
assume I have a better than average chance to convince some on this
list-server). But PC-addicts dont really get an incentive to skip to
another platform when all the software is being ported to them.
I use Windows 3.1 (would you believe) everyday. Its slow, prone to
break down if pressured (booting Netscape comes to mind) and just plain
ugly. Somehow they still get software by the truckload.
I think PCs should be allowed to die in piece. Porting programs to
Windows doesnt really help. I mean, come on, how much more juice can
they get out of those Intel-chips. I expect the next chip to be
delievered with its very own chryogenic cold-cabinet (or something).
(Incidently, I also use Oracle on a daily basis. If the owner of Oracle
really buys Apple, Im jumping in front of bus tomorrow.)
> (e.g. for those of a Speccy background, in Isometric 3D - Knight
Lore, and
> Head over Heels. ).
Yep, I saw Head over Heels. But only because it was ported to Commodore
64 ... erm, what was my point again?
Allan
Date: Sun, 27 Apr 97 20:54:10 -0700
From: James Hague <jhague@dadgum.com>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re: Porting and Platforms. (Tim's Side)
>It would most resemble
>object-oriented programming in that nearly every aspect of the program
is
>broken up into modules. Whenever you wanted to do something you would
>call a subroutine to do it, you wouldn't just do it on the spot.
This is Forth, in a nutshell--the ultimate "break up your problem
into
tiny pieces" language. I used to be a zealot, but have since changed
my
ways :-)
Forth is very cool, but it never seems to survive the transition from
a
nifty way of interfacing with _your_ machine to a system suitable for
doing general purpose application development.
James
Date: Mon, 28 Apr 1997 00:17:17 -0400 (EDT)
From: Figaro Tea <humphret@lurch.winthrop.edu>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re:(2) Porting and Platforms. (Tim's Side)
On Sun, 27 Apr 1997, James Hague wrote:
> This is Forth, in a nutshell--the ultimate "break up your problem
into
> tiny pieces" language. I used to be a zealot, but have since
changed my
> ways :-)
>
> Forth is very cool, but it never seems to survive the transition from
a
> nifty way of interfacing with _your_ machine to a system suitable for
> doing general purpose application development.
I hope you don't write off what I'm saying because there's an entire
language that implements it, but yet just can't cut it. What I'm talking
about is a methodology, and not a proramming language at all. I would
really like it if we could get away from a particular language and look
at it as a fundamental different way of programming. Once we understand
all the ramifications of it then we could possibly even talk about
implementing it as a language. The main point I'm trying to get at, is
that program modulariztion isn't a programming language, but a
programming design technique. Even if it has been implemented in a
language it deserves to be separated from any particular program language
implementation and studied independently.
Program modularization transcends any single programming language.
..._Tim_...
Date: Mon, 28 Apr 1997 07:45:37 +0200
From: Allan Lund Jensen <maccoder@post6.tele.dk>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re: Porting and Platforms. (Tim's Side)
Figaro Tea wrote:
> 2) On One Platform
> However, for this to happen the programs to communicate have to exist
on
> all platforms. Allan's dogma of not porting to Windows will actually
> decrease choice, because a person will have no choice but to buy a
> certain system. If the same *kind* of program existed on both systems,
> preferably the *same* program, then you have the choice between different
> systems. I know many of you absolutely hate Windows, and for good
> reason, but if we don't programs to it and other systems, then we'll
be
> just as bad as Bill Gates. In the long run it doesn't matter which
OS is
> written for as long as they're all written for.
>
Well, you fight fire with fire. Today you actually *can* get the same
kind of programs to different computers, but somehow people still choose
Wintel.
I think we can all agree that if you're looking for cool hardware, PCs
probably isn't the best way to go. Therefor I have always assumed that
PC-fanatics uses them because of the software. So don't give them
anymore.
If they really wanted to play Marathon, use Illustrator or Clarisworks
they should have to buy a Mac.
> If I could counter Allan's story about Joe and the salesman, I would
tell
> Joe that he's getting what he's paying for: cheap crap. I would tell
Joe
> that PCs are initially cheaper but they'll cost you a hell of lot more
> overall because they require constant attention. It's kind of like
> choosing cars: do you choose the cheap fixer upper, or the slightly
more
> expensive reliable one?
I agree. Joe's getting cheap crap. As a first time user Joe didn't know
this. Besides, although he has to upgrade a lot, his friend Leo promises
to suply him with a CD worth of new software each month, very cheap :(
Although it continues to surprise Mac-owners, having the better
equipment, the better software and the nicest users hasn't really
convinced that many people to buy Mac. Wintel is being choosen because
it has the largest following. A bit like lemmings.
> 3) On Program Modularization (aka My programming language)
>
> >From what Allan described it as you would think it's a new programming
> language; but I'm going to go on the record and say, in all caps: IT
> ISN'T A NEW PROGRAMMING LANGUAGE, BUT A NEW *WAY* TO PROGRAM!
It most
> likely isn't even new, just different. It would most resemble
> object-oriented programming in that nearly every aspect of the program
is
> broken up into modules. Whenever you wanted to do something you would
> call a subroutine to do it, you wouldn't just do it on the spot.
Damn! I always get that part wrong ;)
Seriously, as I've said, any misrepresentations of Tim's idea is
entirely my fault.
I think I have a fair idea of what you propose to do.
As far as I remember there was talk at some point of it being something
like a macro-language. But if cross-platform development isn't the point
of this language, what is? I mean, the current way of programming seems
to work okay?
I've choosen assembler because of the speed, so using a lot of branches
and checks (as I assume there will be) seems to be little
counter-productive.
> I haven't sat down to really think this over, but that's the basics
of
> what I'm thinking about. Something you should note, is that you can
do
> this now in assembly, C++, or whatever; you don't need an entirely
new
> language to do this, just a new way of thinking about what it means
to
> create a program.
>
It's a bit like one of those stereograms thingies (you know, those 3d
pictures no one can see what is). I'm certain there's a very good idea
behind this, and I feel I can almost see what it is. But as assembler is
pretty hardware specific, fast and simple (as we agreed) why do want to
switch to a new method of programming?
Allan
From: Stuart Ball <lightsoft@compuserve.com>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re: Porting and platforms (Tim's side)
Tim wrote:
>>It would most resemble
>>object-oriented programming in that nearly every aspect of the program
is
>>broken up into modules. Whenever you wanted to do something you
would
>>call a subroutine to do it, you wouldn't just do it on the spot.
James wrote:
>This is Forth, in a nutshell--the ultimate "break up your problem
into
>tiny pieces" language. I used to be a zealot, but have since changed
my
>ways :-)
>Forth is very cool, but it never seems to survive the transition
from a
>nifty way of interfacing with _your_ machine to a system suitable for
>doing general purpose application development.
Maybe it's because mere humans can't get to grips with the rpn and stack
operations?
I've always liked Forth and used it before z80 assembler as a way of
meeting the machine (which was a ZX81, or TMS 1000 at the time).
I spec. like the way you just compile yourself a new language. Neat.
If I
remember right, the Jupiter Cantab was a purely based Forth machine.
Unfortunately I couldn't afford one at the time :-(
Sorry, it's a little off thread. Pocket Forth is the Mac one I've used.
Stu.
On Mon, 28 Apr 1997, Allan Lund Jensen wrote:
> Today you actually *can* get the same
> kind of programs to different computers, but somehow people still choose
> Wintel.
I hope that it stays that way: programs on all platforms. BTW, I do
know
that there are cross-platform programs out there, I just wanted to point
out that I think it isn't a bad thing.
> I think we can all agree that if you're looking for cool hardware,
PCs
> probably isn't the best way to go. Therefor I have always assumed that
> PC-fanatics uses them because of the software. So don't give them
> anymore.
> If they really wanted to play Marathon, use Illustrator or Clarisworks
> they should have to buy a Mac.
The problem with the Mac's market share isn't lack of programs, but lack
of perception. A lot of people honestly don't know that the Mac exists,
and if it does the current state of it; they're misinformed. People need
to know that the Mac is a viable platform that is capable of meeting
their needs. What Apple needs to do, in my opinion, is to advertise
heavily with the sole intent of informing them that the Mac exists and
about its current state of operations.
I've honestly heard people ask someone else if Apple even exists. I
was
sitting in the library one day and overheard a conversation some Computer
Science 101 people were having. They were talking about different
computer companies and one of them really asked if Apple was still
around. It's this kind of perception problem that Apple needs to
overcome; not hording programs--actually this wouldn't do any good anyway
because people don't even know the Mac exists, OpenDoc's cool and all but
most people don't even know it exists, or did anyway.
> I think I have a fair idea of what you propose to do.
> As far as I remember there was talk at some point of it being something
> like a macro-language. But if cross-platform development isn't the
point
> of this language, what is? I mean, the current way of programming seems
> to work okay?
> I've choosen assembler because of the speed, so using a lot of branches
> and checks (as I assume there will be) seems to be little
> counter-productive.
I think the macro thing you're talking about is the high-level assembly
I
was talking about and not program modularization--even still, they got
that partially wrong too by trying to make it into a just a macro language.
I hate to get a little rude here, but... It amazes me that you guys,
or
maybe just you Allan, STILL can't get what I'm saying, or otherwise get
it wrong. I'll say it, again, in plain english of what I'm talking about.
----------
Program modularization will allow you to easily modify and
maintain your program. By breaking up every aspect of it into
well-defined subroutines that do only one task, then the program has the
potential to become more efficient and powerful. This occurs, because
like assembly it will use only simple "instructions", subroutines,
to get
its tasks completed. By breaking functionality up into different pieces
then you can combine the subroutines together to make a more robust and
efficient program. A SIDE BENEFIT of this is that it will be easier to
port programs to different platforms because all the OS-specific code
should be in it's own isolated subroutine. Therefore, changing the OS calls
is easier because the other subroutines don't know about the operations
of other subroutines, only how to communicate with it: as long as the
communication between subroutines remains unchanged, a particular subroutine
can be implemented in any fashion on any OS/platform.
----------
There, that in a nutshell is what I'm talking about. I'm going to keep
a
copy of this message, and if anyone still says they don't understand I'm
just going to repost this same message; I just don't see a simpler way of
stating it. Oh, and to respond to your statement about using a lot of
branches and checks...Program modularization wouldn't speed up things, if
anything it would slow it down a tad because the program would have to do
a lot of "asking" instead of assuming. The benefit will be to
make
programs easier to modify and maintain. (Speeds of processors have
gotten to the point that you probably wouldn't even notice the slowdown.)
..._Tim_...
Date: Tue, 29 Apr 1997 01:51:15 +0200
From: Allan Lund Jensen <maccoder@post6.tele.dk>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re: Porting and Platforms + assembly
(I've taken the liberty to merge both threads. I obviously don't grasp
the fundementals anyway, so I figured: what the heck :)
> The problem with the Mac's market share isn't...
Right and wrong. I agree with what you say about people not knowing
about Macs. But lack of programs is still a problem. I dont know how
into games you are, but you have to realise that many people buy
computer from that point of view. Getting Command & Conquer a year after
the original, doesnt really cut it. Sure, people want access to
spreadsheets and wordprocessors, but they also like to kick back with a
game of Quake (or whatever).
> I hate to get a little rude here, but... It amazes me that you
guys, or
> maybe just you Allan, STILL can't get what I'm saying, or otherwise
get
> it wrong. I'll say it, again, in plain english of what I'm talking
about.
Dont worry, Im hard to offend ... just dont mention mother :)
Since you came up with the idea, and you say I dont understand, well
then I obviously dont ;)
As Ive said, I *do* think I understand. Not completely, couldnt
explain it to someone else, but I definitely think Im getting what you
mean (although I might not use the right terms). But I suppose thats as
close to not understanding you can get ... okay then, put me down for
one of those undecided thingies.
> The benefit will be to make programs easier to modify and maintain.
(Speeds
> of processors have gotten to the point that you probably wouldn't even
notice > the slowdown.)
Most definitely depends on the type of program. Granted, assembler is
fast, but you still spend time optimizing. Even though processors get
faster, we keep asking more from them.
> I think assembly can be a processor-independent language, thereby
becoming a
> true language like C++.
Okay, here I will admit defeat. I assume were speaking about PPC
assembler, or are we talking about defining a standard
assembly-language?
Either way, why would you ... why?
Since youre saying processor-independant, I assume this assembler-code
would have to be translated to whatever version of assembler the
machines processor is using?
Now, I love PPC just as much as the next guy, but this Im not too sure
of.
In any case, the difference between different versions of assembler is
not too great. I mean, if you know 68k then PPC is fairly easy to pick
up (not that Im by any means particulary good at either). Heck, even
Intel makes some sense. Why sacrifice time translating a program, when
you could fairly easily learn a new dialect?
> i.e. identifying which instrucions are essential,
I wouldve thought that we with RISC computing are cutting it pretty
close to the bone, as it is. The FPU still doesnt make sense to me,
though, so I suppose we can leave that out ;) Although I did read the
PPC supposedly supports an FPU-instruction called fsqrt, which,
obviously, calculates squareroots. It also said it would take about 100
clock-cycles. Still, pretty cool, if it's true, no?
> I don't want this kind of power locked into a specific processor,
the way
> assembly is now.
> If it does stay locked then we'll be stuck with crap languages like
C++
> forever.
Stop me if Im wrong, but its not like someone makes a processor and
then later decides for language for it. Im pretty sure that what you
just said is contradictory in terms. Assembler is by default locked to
a specific processor. I assume altering assembler means altering the
chip. I think youll have to redefine the term assembler as you use it.
As it is, assembler means 68k, PPC, Intel and so on.
Ive got the nagging suspicion that Ive mistunderstood you again, Tim.
But before someone paste a Kick me-sign on my back, I freely admit Im
talking about stuff I dont know too much about; designing new languages
is not one of my best subjects. This might a be a good place for someone
more knowledgeable to paste some text in ... Rob? Stu? Anybody? How does
assembler/a processor *really* work. In two lines or less?
If we overlook the fact that I dont understand (erm...), I certainly
agree that assembler shouldnt die (although I have a hard time
picturing a computer that doesnt use assembler).
But, I must admit, its a great idea: anything to make assembler live
forever.
Although I do suspect, that if this idea is shared with
non-assemblerprogrammers they will look at you strangely and say: You
want to WHAT?
Mmm, if this a bad day for me, Ive misunderstood everything youve said
Tim. Sorry. I can only suggest either a) Be more specific, dont think
Ill be the only slow learner youll meet, or b) Switch to danish. If I
were you Id definitly go with option a) ... or c: c) Give up, Allans
never going to understand.
... so ... how about those Celtics?
Allan
P.S. Although I make a fool of myself daily, it's not something I
actively pursue. In other words, if I'm the only one not getting this
I'm perfectly willing to say 'uncle'. I suspect most of you have better
things to do than watching re-runs of "Educating Allan".
...I still don't believe in single platforms, porting or windows (he
said defiantly as they dragged him away, kicking and screaming)
Date: Mon, 28 Apr 1997 21:09:43 -0400 (EDT)
From: Figaro Tea <humphret@lurch.winthrop.edu>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re:(2) Porting and Platforms - assembly
On Tue, 29 Apr 1997, Allan Lund Jensen wrote:
> (I've taken the liberty to merge both threads. I obviously don't grasp
> the fundementals anyway, so I figured: what the heck :)
Not to act like I know what's always the best, but I think it would be=20
better to separate the topics. This way we can minimize some of=20
the confusion that might result when you read a comment that pertains=20
only to a particular thread. I'm going to make sure you at least=20
understand what I'm talking about, Allan:)
> Right and wrong. I agree with what you say about people not knowing
> about Macs. But lack of programs is still a problem. I don=92t know
how
> into games you are, but you have to realise that many people buy
> computer from that point of view.=20
Lack of programs is a problem that is caused by the perception that there
isn't even a Mac...how's that:) You're right though, the program issue=20
is going to have to be resolved, maybe at the same time as the perception
problem. I do realize that people buy computers with the games in=20
mind--I like relaxing every now and then by blowing the guts out of some=20
Pfhor:)
> Don=92t worry, I=92m hard to offend ... just don=92t mention mother
:)
> Since you came up with the idea, and you say I don=92t understand,
well
> then I obviously don=92t ;)
> As I=92ve said, I *do* think I understand. Not completely, couldn=92t
> explain it to someone else, but I definitely think I=92m getting what
you
> mean (although I might not use the right terms). But I suppose that=92s
as
> close to not understanding you can get ... okay then, put me down for
> one of those =93undecided=94 thingies.
Glad to see you're a good sport about this. How about you tell me what=20
you think I mean about program modulariztion, i.e. explain to me what=20
I've said. I really want people, especially you Allan, to understand=20
what I mean; program modularization could really be beneficial to the=20
design of programs.
BTW, on the issue of Forth. I've checked out some info about it on the
web=
,and it's somewhat of what I want, but the fact that it's a stack based
language and is interpreted looks pretty, well, bad to me.
> Most definitely depends on the type of program. Granted, assembler
is
> fast, but you still spend time optimizing. Even though processors get
> faster, we keep asking more from them.
The point of program modularization is *not* speed, it's maintainability.
I think you may be looking at this the wrong way. This is an assembly
list-serv, I know, but this concept of program modularization has
absolutely nothing at all to do with assembly. It just so happens that=20
I decided to bring the issue up on this list-serv, I could've just as=20
well done it for a C++ list-serv--and if I was primarily a C++=20
programmer I probably would have. I'm mainly talking in abstract terms,=20
not specific ones such as the speed loss of using branches and checks. =20
Does this sorta make it clear?
BTW, we still have yet to discuss any details about it. So far we, or=20
maybe just me, have been trying to explain clearly what it is. I'm just=20
bringing this up because I don't want you all to think that this discussion=
is done yet, far from it:)
..._Tim_...
--=3D[Live your life in the present, history will make itself in the future
http://www.winthrop.edu/~humphret
zzhumphreyt@winthrop.edu
Date: Mon, 28 Apr 1997 16:17:29 -0400 (EDT)
From: Figaro Tea <humphret@lurch.winthrop.edu>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Assembly As a True Language
This message would've been included in the other one, "Porting and
Platforms", but I don't want to invite confusion between what I'm going
to say here and what I said there.
Allan said this stuff
> But as assembler is
> pretty hardware specific, fast and simple (as we agreed) why do want
to
> switch to a new method of programming?
The fact that this is an assembly list-serv is irrelevant to me. Even
though assembly is fast and efficient it could still benefit from a
different way of doing things. As I said to you, Allan, I think assembly
can be a processor-independent language, thereby becoming a true language
like C++. My personal reason for programming in assembly is its
simplicity, which enables it to be fast and powerful. I don't want this
kind of power locked into a specific processor, the way assembly is now.
If it does stay locked then we'll be stuck with crap languages like C++
forever. Kevin and I both wrote two simple programs that did identical
things, but written in assembly and C++. The results, of course, showed
that assembly is tremendously more efficicient than C++. Our examples
however only showed the space efficiency. Assembly is efficient because
it does what it's supposed to do and nothing more.
Do you guys really want to see a language like this die? It will, if
we can't find a way to make it more portable; otherwise, more and more
people will choose high-level languages like C++ to write their programs
in. If this happens then we'll be stuck with programs that are
ridiculously huge in relation to what they do.
Do you guys remember Sloop, an extension that does something similar
to
what Mousigator does? Although Mousigator doesn't do exactly everything
that Sloop does, it is nearly 11 times *smaller* than Sloop and yet does
practically the same thing. Unfortunately, Mousigator will only be 68K
due to the tremendous amount of work required in rewritting to a different
processor; on the other side, Sloop is both 68K and PPC, simultaneously.
This kind of discrepancy will continue to exist in other programs, and will
only get worse as different OS and processor use become common place.
People will prefer to use a program that exists on multiple platforms,
rather than using a similar program that does the same thing--mainly
because they'll know how to use the same program immediately.
I, for one, don't want to see assembly die, because like a certain computer
type, it is so much more better than anything else out there. My
solution is what I've proposed earlier on this list-serv: high-level
assembly. This is something totally different, separate, and distinct
from the program modularization that I've been talking about--which is
why I separated this message from the other one. It deserves to be
studied in detail, i.e. identifying which instrucions are essential, ...
It
should not be delegated to a mere macro language like others were
proposing; although macros could be used in constructing it.
The use of assembly as a general purpose langauge can be brought about
if it can be made to be portable. It will most definately be something
different than the assembly that we know and love. But as long as the
simplicity that is its heart & soul survives, then it will exist--and
it
will be glorious.
P.S. Many of you may think that I'm fanatical about this, and program
modularization. And you'd be right! I sincerely believe that these two
things can change the way that we as developers and end users experience
computing; and I won't stop singing their praises until they fully exist.
..._Tim_...
--=[Live your life in the present, history will make itself in the future.]=--
http://www.winthrop.edu/~humphret
zzhumphreyt@winthrop.edu
On Tue, 29 Apr 1997, Allan Lund Jensen wrote:
> I assume we=92re speaking about PPC
> assembler, or are we talking about defining a =91standard=92
> assembly-language?
> Either way, why would you ... why?=20
Okay Allan, get ready, cuz here comes a big shout. DID YOU READ MY=20
PREVIOUS POST AT ALL?! Why would you?! Because assembly will always be=20
relegated to writting the "fast bits" and never used as a general=20
purpose progamming language. In this day and age of porting to every=20
system imaginable it makes absolutely no sense to write something that=20
*can't* be ported to a different system, i.e. writting in assembly. =20
Granted you could port an assembly program, but you'd really have a=20
daunting task ahead of you. Assembly has such potential...
I see assembly for what it is: an elegantly simple language that places=20
absolutely no restrictions on what you as the programmer can do. I don't=
want the time to come when it is no longer feasible to program in it--I=20
think that day may already be here... Assembly language may have been born=
from the processor but it's not going to live there; if it does then it=20
will die there.
Assembly is a language all its own. The actual instructions vary from=20
processor to processor but the basic idea of how to program in it are=20
constant: there's a stack you can use to save temporary variables, you=20
have to use things called registers to hold your data, usually the=20
instructions are so simple that they only do a tiny bit of a goal that=20
you have in mind; do you see what I'm talking about? Assembly can make=20
programs that will run circles around any other program; it can make=20
programs that are drastically smaller than anything produced from its=20
nearest competitor; but alas, assembly simply can not live outside of its=
processor. It's this language that I want divorced from the processor=20
and given over to a compiler.
I suppose that since everyone doesn't think like me that it may take
awhile=
to separate the concept of processor assembly to language assembly; I guess=
it is a radical new concept. But I'm going to be here to help anybody=20
that doesn't see it.
> Since you=92re saying processor-independant, I assume this assembler-code
> would have to be translated to whatever version of assembler the
> machines processor is using?
Righto. It's going to be an entirely new language, one that is=20
independent of the processor, so it will have to be translated to a=20
processor. This new language, whatever its name will be, is going to=20
have the best elements of assembly: the simplicity, the freedom to do=20
whatever you want, the power. Of course, since it's going to be derived=20
from assembly it'll probably look just like it.
Are any of you familiar with SAL? This is an assembly language that
is=20
commonly taught to college kids taking an assembly class. Basically in=20
SAL you write your programs using the constructs of assembly, i.e. really=
short instructions that do only a little bit, but you don't have all the=20
nuances of it, like choosing which register to put your data. The point=20
of it is to get them mentally ready to handle real assembly. I see SAL=20
as a starting point of an entirely new language, and not just as a primer
to
learning real assembly.
> Why sacrifice time translating a program, when
> you could fairly easily learn a new dialect?=20
Because it takes time to translate every single line of code, time that=20
someone else will use to beat you to the punch with C++.
> I would=92ve thought that we with RISC computing are cutting it
pretty
> close to the bone, as it is.
Hopefully after reading this message you'll realize what I'm talking=20
about so that I don't need to address this issue: the issue that we don't=
need a new assembly language since PPC is cutting edge and could be a=20
standard.
> > I don't want this kind of power locked into a specific processor,
the way
> > assembly is now. =20
> > If it does stay locked then we'll be stuck with crap languages
like =20
> > C++ forever.
>
> Stop me if I=92m wrong, but it=92s not like someone makes a processor
and
> then later decides for language for it. I=92m pretty sure that what
you
> just said is contradictory in terms. Assembler is by =91default=92
locked to
> a specific processor. I assume altering assembler means altering the
> chip. I think you=92ll have to redefine the term assembler as you use
it.
> As it is, assembler means 68k, PPC, Intel and so on.
Oh Allan, I will convert you yet:)
What I said isn't contradictory, it's discussing assembly in a whole
new=20
way; one that, from what I'm sensing from you Allan, I don't think many=20
people have even considered before.
> I=92ve got the nagging suspicion that I=92ve mistunderstood you
again, Tim.
> But before someone paste a =91Kick me=92-sign on my back, I freely
admit =
I=92m
> talking about stuff I don=92t know too much about; designing new languages
> is not one of my best subjects. This might a be a good place for someone
> more knowledgeable to paste some text in ... Rob? Stu? Anybody? How
does
> assembler/a processor *really* work. In two lines or less?
I'm just beginning to realize what a new concept this probably is to
other people. You have to understand that from my point-of-view what I'm
saying about high-level assembly makes perfect sense. Again, if anyone
doesn't understand I'll enlighten as needed.
> Although I do suspect, that if this idea is shared with
> non-assemblerprogrammers they will look at you strangely and say: You
> want to WHAT?
Which is why I want to do it so much, to show then that it can be done,
that
there does exist a better way of programming. Is my idea really so
radical: divorcing assembly from the processor? I'm just curious,=20
because in my mind it seems quite normal.
> Mmm, if this a bad day for me, I=92ve misunderstood everything you=92ve
said
> Tim. Sorry. I can only suggest either a) Be more specific, don=92t
think
> I=92ll be the only slow learner you=92ll meet, or b) Switch to danish.
If I
> were you I'd definitly go with option a) ... or c: c) Give up, Allans
> never going to understand.
I think I'll choose 'a', thank you:) Eventually, anyone will be able
to
understand what I'm talking about, even you Allan:)
..._Tim_...
--=[Live your life in the present, history will make itself in the future.]--
http://www.winthrop.edu/~humphret
zzhumphreyt@winthrop.edu
From: Stuart Ball <lightsoft@compuserve.com>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Porting+platforms+assembly
The way I see it is this.
All computers run machine code. Fact of life. Instruction in from memory,
decode and find operands, execute, store any result. End of story.
Now how that machine code is put together is the important bit. There
are
just two ways.
1. A human creates it with an assembler.
2. A program creates (i.e a compiler).
Either way, at the end of the day it's machine code.
Because humans are infinitely more creative and clever than a compiler
(and
after all, it was a human that designed the chip that is executing the
machine code) assembly language will always offer speed and size advantages
over compiled code. Compiled code offers advantages of reduced creation
time (sometimes).
A universal assembly language will suffer in that it has to be reduced
to
the lowest common denominator - it would not be able to take advantage of
any one processor specific "goodies". Assembly language programmers,
when
confronted with a new chip always look for the goodies. E.g. new, sexy
instructions a la PPC shift/rots with mask, trinary operands, multiple cc
flags etc.
Bi-language translators do not suffer this problem as they have rigidly
specified source and target processors. For example we will be producing
a
68k to PPC macro translation set that is (are) end user editable. Here we
have an example of a mechanism that does not cover all eventualities but
does offer the end user the ability to modify the set and produce what is
wanted. By doing this the end user creates a super-set of the original
without sacrificing any compatibility.
For the record, I believe there will never be one common platform because
there will always be a manufacturer who thinks he can do better, and that
the world deserves better. In a way, prep takes us back to the 80's when
the very first micro hit the scene. Other manufacturers said "hey we
can do
better than that". That is how technology progresses. There would have
been
no Amiga (soon to make a re-emergence from the past on 603/4...) for
example if this was not the case.
From yesterday...if we really must have just one OS, as long as it's
from
Apple (bless 'em) I couldn't care less :-)
And yes, I believe Allan is right when he says that new PC users bought
a
PeeCee because they knew of no alternative. It's they're own fault. I have
no time for PC user with problems. The PC architecture is dreadful.
Specifically the memory "system" and processor. The only answer
you can
give them is "Sell it and get a Mac".
Stu.
Date: Mon, 28 Apr 97 21:30:36 -0700
From: James Hague <jhague@dadgum.com>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re:(2) Assembly As a True Language
Tim said:
>Is my idea really so
>radical: divorcing assembly from the processor? I'm just curious,
>because in my mind it seems quite normal.
With all seriousness: that's why C was invented, to be a high-level
assembly language. As Stu pointed out, if you try to make a generic, but
still usable, assembly language, then you basically give up many of the
reasons for writing in assembly in the first place. So you might was
well abstract things a bit more and come up with a language in which each
contruct can be translated into machine code very simply.
If you go back an read the original K&R book on C, this philosophy
is a
lot more apparent than with ANSI C. You had things like "structure
member names must be unique across all structures" and "you can't
pass a
structure as a parameter, only a pointer to a structure." Things that
got in the way of a clean C -> assembly translation were omitted.
And in a different message he said:
>Program modularization wouldn't speed up things, if
>anything it would slow it down a tad because the program would have
to do
>a lot of "asking" instead of assuming. The benefit will be
to make
>programs easier to modify and maintain. (Speeds of processors have
>gotten to the point that you probably wouldn't even notice the slowdown.)
IMO processors have been fast enough for the last ten years. I wrote
a
text editor in Turbo Pascal on my 8MHz 8088-based PC in 1989. No
assembly whatsoever. The compiler was faster than GNU C on a 486, and
the resulting text editor was amazingly fast (except for searches). When
I see people complaining about 486s not being fast enough for simple
things, or Pentiums, or the PPC 601: no offense, folks, but you're doing
something wrong. I don't think it's the little things like checks and
such (my text editor ran at the same speed with range checking, stack
checking, etc., turned on as it did with them off), but huge, gross ways
of writing code, like pasting big libraries together blindly.
Ah, well, back to work :-)
James
Date: Tue, 29 Apr 1997 15:56:52 +0200
From: Allan Lund Jensen <maccoder@post6.tele.dk>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re: Porting+platforms+assembly
Okay, first of all in retrospect I probably shouldnt have merged the
two threads. Ill do it just once more, because Tim confused some of the
things I said about assembly with some thing about modular(?)
programming. My fault entirely ... sorry
First the assembler stuff.
I think that the reason I dont understand/misunderstand Tim, is because
we use assembly differently. I think you, Tim, use assembler for
useful programs, applications, while Im a bit more effects/games
oriented.
Couple this with the fact that you think porting is a great idea, or
rather a 'must' these days, were bound to disagree.
I love assembly, and if I had to list the 10 best things about it, speed
would be the first 5.
You will loose speed, when youre compiling from a language to the
specific computers native assembler. Even though were probably talking
about very little in this specific case, *it is speed I cannot afford to
loose!!!*.
It might not mean much to a wordprocessor or a drawing programming, but
if youre trying to plot as many polygons as possible on a screen, its crucial.
Also, I dont think porting is a good idea. Ive explained why in other
posts, so I wont go into too much detail.
Wintel machines has got the largest market share. Personally I find that
depressing, so I will not port anything to wintel. I find it hard to see
financial reasons for doing this, unless your *real* sure youve got a
hit.
Its old technology without any sense of progress (besides sticking a
new Intel chip in them every other year).
The conclusion:
I dont intend to port anything (should I ever make a program, that is),
thus I dont mind using hardware-specific assembler. For what I actually
*do* make in my spare time, I need every bit of speed I can get. Using
assembler wouldnt make sense to me, if it wasnt native.
>> Why sacrifice time translating a program, when
>> you could fairly easily learn a new dialect?
> Because it takes time to translate every single line of code, time
that
> someone else will use to beat you to the punch with C++.
Im not talking about converting an assembler-program from one platform
to another, Im talking about starting from scratch. Im sure youll
agree the jump from 68k to PPC isnt that great. I see no reason why the
learning curve would be any higher on other chips.
BUT, having said all that, I must admit I like your way of thinking.
Youve obviously said: well, besides the speed, assembler is actually
pretty nice to work with. Its simple, hands-on and its got the nicest
users.
I actually think I know what youre talking about :)
There is a lot of sense in what youre saying. But this new assembler
youre talking about is not, actually, assembler. It might look like it,
it might work like it, but I still say it isnt assembler. You should
think of another world (H.I.A.?) But thats just me being oldfashioned.
Instead of spending time convincing people to buy/use a new
programming-language I would rather spend my time convincing Mac-users
to use the chip theyve already got.
Hardwareindependant assembler: great idea, I like it. Wouldnt use it, though.
Not before I had no way to talk to my own processor diretly, or when
they start selling 1GHz processors ... and then, only maybe.
Im still willing to be convinced, Tim, but you gotta give me ALL the
speed of assembler. And that means hardware-specific assembler. Sorry ;)
> Oh Allan, I will convert you yet:)
Okay, but dont convert me to Windows ... yeah, yeah, I know...
And now (argh) modularization:
Im in kind of a predicament here. Lets look at a few quotes:
Me: I *do* think I understand. Not completely, couldnt explain it to
someone else...
Tim: How about you tell me what you think I mean about program
modulariztion.
So I couldnt explain it to anyone else. Tim wants me to explain.
Yep, just me, a rock and a hard place ;)
Here goes nothing:
As I understand it, Tim, youll avoid doing anything hardware-specific
in the main program. This will be done by hundreds of subroutines.
These subroutines are in a way, selfcontained. They do not speak to
eachother on any level of the hardware, their interaction is entirely
defined by the software (the language). Porting programs using this
language requires no change of the main-program, but only to the
abovementioned subroutines. Since these routines are made for many
different platforms, a program made in this language will run on all
platforms. Improving programs is only a question of either a) optimizing
the main-program b) improving the sub-routines (if youre really
cool).
Okay, tell it like it is. Am I even close? Even if Im not, could you
please lie? Just kidding.
Should you grade on a scale from 1-10, how close am I?
> I like relaxing every now and then by blowing the guts out of some Pfhor:)
Common ground at last. Eat plasma-death, aliens!
Allan
Date: Tue, 29 Apr 1997 12:32:45 -0800
From: Kevin Avila <kevin@cache-computing.com>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re: Porting+platforms+assembly
Stu put it best when he said that you will never have a standard
assembly, because each chip maker will think that it can be better. Porting
assembly programs has always been an issue with every language. Some are
easier then others. If I am correct, Tim only does 68K assembly, correct?
This being the case Tim has a far better atvantage over PowerPC assembly
geeks because Wintel chips share a similar lingo to the 68K chips. the 68K
'move.l' on wintel it's 'movl' Very simple. However, if you read the x86
tech docs, you will find there there is nothing that even comes close to
the PowerPC's function like quadrupile half-bit division with added 0 or
whatever. Porting will assembly by hand is not really that practical. When
I have a program that I want to be ported, What I do is write the function
is C, boot up my OpenOS box, and compile the C program with GCC and the
-S
tag. What this does is dump the assembly code for that function in ANY
processor I want. So with one C function I make code that runs on 68K,
PowerPC, Intel, Alpha, Sun, etc. I can then go over the code and optomize
it.
Stu reported to me yesterday that phase 3 of Anvil will be going out
to
testers real soon. So, if the IDE is any good, I hope to have a tool ready
when it is released that implaments that function of GCC. It's really the
only way to go. :)
----------------------------------------
Kevin Avila http://www.cache-computing.com
kevin@cache-computing.com
Date: Tue, 29 Apr 1997 23:24:42 +0100
From: Rob Probin <rob@zedworld.demon.co.uk>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re:(2) Assembly As a True Language
>IMO processors have been fast enough for the last ten years.
I both agree and disagree with this statement.
For:
People who need to upgrade their machines to get their latest word
processor to run at an acceptable speed should really ask if the word
processor writers are in bed with the hardware manufacturers. (e.g. WYSIWYG
= conned PC owner, I was using that on my speccy with proportional type
faces, remember thats a 48K memory machine with a 3.58Mhz Z80. In fact I
didn't _KNOW_ what WYSIWYG was until I used a PC....).
Against:
I _still_ can get my real-time ray tracer running at 30fps.
On a different argument:
When has Joe Public ever bought the more expensive 'technologically better'
system, over one that 'appears' to do the same job, but is actually better.
(I have _lots_ of examples of the poorer but cheaper system winning - what
I would like is a few counter-examples).
On languages that are non-computer specific:
Show me ONE language which is computer non-specific (apart from JAVA -
which only runs on a subset of machines anyway). Isolation of the processor
and OS is NOT enough. You must also isolate the hardware, and environment.
(As a footnote: OS's don't give you total hardware isolation).
So why doesn't everyone write in JAVA, or similar????
(and how come the Press seem to be over the moon with Java, but they don't
write programs for a living???).
Rob
Date: Tue, 29 Apr 1997 18:05:43 -0500
From: "robert c. wagner" <rcw@texas.net>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re: (2) Assembly As a True Language
Rob Probin wrote:
> On languages that are non-computer specific:
>
> Show me ONE language which is computer non-specific (apart from JAVA
-
> which only runs on a subset of machines anyway). Isolation of the processor
> and OS is NOT enough. You must also isolate the hardware, and environment.
> (As a footnote: OS's don't give you total hardware isolation).
>
I have used versions of forth that where isolated from the "computer".
I have worked in one such environment where we could move from IBM
mainframe, to Vax/VMS, to Tandem with the *exact* same source. Some of
those machines byte swapped others didn't, some used block mode sync
terminals, some used full duplex character mode terminals, some used
ebcdic some ascii (keep in mind the collating sequence issues that had
to be addressed), and it was all transparent to the application
programmer.
I also seem to recall that there was some thought about using forth for
the brains behind plug and play cards (like PCI) as well, but I don't
know if that was ever adopted.
I personally developed derivations of forth for three different
platforms. Once the nucleus is created the rest is a snap! Some of the
same skills that make a good assembly language programmer also make a
good forth programmer. For example, managing your own data types,
stacks, memory leaks, and parameter passing require pretty much the same
level of detail in both environments.
There has even been hardware implementations of forth engines for use
in
embedded system like traffic light controllers. (Now if we could only
get some intelligent traffic lights here in Austin... well I could dream.)
robert
Date: Tue, 29 Apr 1997 20:31:21 -0400 (EDT)
From: Figaro Tea <humphret@lurch.winthrop.edu>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re: Porting+platforms+assembly
On Mon, 28 Apr 1997, Stuart Ball wrote:
> A universal assembly language will suffer in that it has to be reduced
to
> the lowest common denominator - it would not be able to take advantage
of
> any one processor specific "goodies". Assembly language programmers,
when
> confronted with a new chip always look for the goodies. E.g. new, sexy
> instructions a la PPC shift/rots with mask, trinary operands, multiple
cc
> flags etc.
Even in true assembly langauge you sometimes don't use all the
processor's sexy instructions. Since I want my programs to work on all
Macs I only use 68020 instructions, if I wanted to use move16, a 68040
instruction, then a lot of other Macs would be left out. The fact that
in high-level assembly you can't use these sexy instructions isn't any
different.
On the lowest-common denominator issue I'll just say this. Since the
code
that you type in for high-level assembly is processor-independant and the
code ultimately has to be translated to true assembly, some of the
processor's sexy instructions could get used; it mainly depends on how
the translator is written.
> Bi-language translators do not suffer this problem as they have
rigidly
> specified source and target processors. For example we will be producing
a
> 68k to PPC macro translation set that is (are) end user editable. Here
we
> have an example of a mechanism that does not cover all eventualities
but
> does offer the end user the ability to modify the set and produce what
is
> wanted. By doing this the end user creates a super-set of the original
> without sacrificing any compatibility.
I think that since high-level assembly will be derived from assembly
that
it should offer the ability to write processor-dependent code. The way
I
envision it is that the user could see the actual processor instructions
that are being produced and edit them to optimize the program. This, of
course, is exactly what you're saying. While I'm trying to sell this
idea to you guys I'll be on the lookout for good ideas to implement: like
your bi-language translator idea, Lightsoft--I know you guys probably
didn't think I'd be using and embracing your idea, but congratulations
anyway:)
> For the record, I believe there will never be one common platform
because
> there will always be a manufacturer who thinks he can do better, and
that
> the world deserves better.
I agree with you on this one. The thing is, is that the new platform
is
going to have to be compatible with the current standard if it's going to
be widely accepted. If it can't interface into the mainstream then it'll
probably wither away and die. It can introduce it's own new way of doing
things, but it's going to need an option that supports the current standard.
..._Tim_...
--=[Live your life in the present, history will make itself in the future.]=--
http://www.winthrop.edu/~humphret
zzhumphreyt@winthrop.edu
Date: Tue, 29 Apr 1997 21:39:46 -0400 (EDT)
From: Figaro Tea <humphret@lurch.winthrop.edu>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re: Porting+platforms+assembly
On Tue, 29 Apr 1997, Allan Lund Jensen wrote:
> First the assembler stuff.
>=20
> I think that the reason I don=92t understand/misunderstand Tim, is
because
> we use assembly differently. I think you, Tim, use assembler for
> =91useful=92 programs, applications, while I=92m a bit more effects/games
> oriented.
I suppose that we do use it for different things. I want to
comment on something that James said earlier about the similarities of=20
high-level assembly and the origins of C. C may have originated as=20
something similar to what I'm saying, but it's mutated into something far=
=20
from that. I just had a horrible battle with C++ about multiple=20
inheritance and classes: it pretty much wouldn't let me use functions in=20
another class that I had written because it claimed they didn't exist. =20
The part I want to comment on is that I sometimes find myself dealing=20
more with the language than I do with my program, especially when you start=
=20
doing some really advanced stuff. Assembly is by no means devoid of=20
hassles, but since it pretty much lets you do whatever you damn well want=
=20
you don't get into to many scruffles with the actual language itself. =20
With C++, and most other high-level languages, you have to follow their=20
rules on how to do things: you can't just do things the way you want to=20
do them. Assembly is so neat because it doesn't come with rules on how=20
to do things, except the ones the processor itself imposes; however, you=20
can still get around these with minimal hassle, like the pc-relative=20
addressing mode for destination operands in 68K. This just serves to=20
highlight one of the many things that I like about assembly: few rules to=
=20
abide by. My desire to make assembly into a portable language isn't so=20
much to have a common true assembly, but to have a language that has all
the
best features of assembly. C may have been slated to be this kind of=20
language, but it's strayed far from its roots.
> You will loose speed, when you=92re compiling from a language to
the
> specific computers native assembler. Even though we=92re probably talking
> about very little in this specific case, *it is speed I cannot afford
to
> loose!!!*.
I don't think true assembly is ever going to die, so I don't think you=20
don't have to worry about anything that I'm saying Allan. Although,=20
after reading what I said in a previous post about the option to see and=20
edit the true assembly that the high-level assembly is producing, you might=
consider writting in it.
> Also, I don=92t think porting is a good idea. I=92ve explained why
in other
> posts, so I wont go into too much detail.=20
> Wintel machines has got the largest market share. Personally I find
that
> depressing, so I will not port anything to wintel. I find it hard to
see
> financial reasons for doing this, unless your *real* sure you=92ve
got a
> hit.
|> It=92s old technology without any sense of progress (besides sticking
a
> new Intel chip in them every other year).=20
Porting is not synonymous to Wintel ports. Porting is good because a=20
commonality can evolve that will benefit end users tremendously. =20
Sometimes, we as developers are so interested in getting the users to use=
our product that we don't consider the impact that breaking a standard,
a
commonality, can have on them. Allan, if you personally don't want to=20
port to other platforms, then that's fine; but I'm going to always=20
counter anything negative you say about porting, even if at times that=20
means defending the Wintel platform.
> I=92m not talking about converting an assembler-program from one
platform
> to another, I=92m talking about starting from scratch. I=92m sure you=92l=
l
> agree the jump from 68k to PPC isn=92t that great. I see no reason
why the
> learning curve would be any higher on other chips.
The switch from 68K to PowerPC wasn't that bad because both chips ran=20
under the same OS. When you talk about chips that run under other OSs=20
then an additional learning curve is introduced, that of the OS. Either=20
way, it's a lot of waste to have to continually learn new processor=20
conventions--not that I'm against continual learning, I'm actually for=20
it. I personally like to see how my programs run under different=20
processors and OSs, but staying bound to true assembly won't allow that=20
which is why I'm advocating a high-level incarnation.
Allan, if you only ever write small snippets of code, then relearning
a=20
new processor and writting the same program from scratch wouldn't be all=20
that burdensome; but for the programs that I'm writting, and will write,=20
this is intolerable. I don't want to give up the things that I like=20
about assembly just because I want to execute my programs under different=
=20
processors: if a solution to my dilemma doesn't yet currently exist then=20
I'll make one, and high-level assembly is going to be it.
> There is a lot of sense in what you=92re saying. But this new assembler
> you=92re talking about is not, actually, assembler. It might look like
it,
> it might work like it, but I still say it isn=92t assembler. You should
> think of another world (H.I.A.?)
I know it's not going to be true assembly, which is why I'm going to
start calling the assembly of the processor, true assembly. As for a
name for my high-level assembly, I haven't thought of one yet, any=20
ideas? For now though, I'll just call it high-level assembly.
I think that the assembly language of the processor and assembly language=
are different. Processor-assembly is the actual instructions and nuances=
of a particular process: for 68K you can't have pc-relative instructions=20
as the destination for an instruction, words are two bytes and not four,=20
... Assembly language, on the other hand, are the methods to program that=
are common across all processors: you have to use registers to hold data,
you can only use one instruction at a time to get things done, there are=20
no explicit data structures other than bytes and words, ... Assembly=20
language is what I want in high-level assembly; not processor-assembly,=20
it can stay where it is.
> But that=92s just me being oldfashioned.
> Instead of spending time convincing people to buy/use a new
> programming-language I would rather spend my time convincing Mac-users
> to use the chip they=92ve already got.
Good point, but eventually they're going to have to use another chip
and=20
get used to it. How would you like it if human languages were constantly
changing: you currently speak english for a year, but I wouldn't get used
to
it because french is going to be the hot thing next year, but before you=20
get used to ordering hors d'oeuvres you better prepare for german because=
it's looming on the horizon, and some say that it's smokin'. Can you=20
imagine this scenario? You can. Just take a look at the current state=20
of assembly.
> I=92m still willing to be convinced, Tim, but you gotta give me
ALL the
> speed of assembler. And that means hardware-specific assembler. Sorry
;)
Well, maybe high-level assembly isn't your cup of figaro tea. Sad=20
though, it hasn't even been created and you're already writting it off.
..._Tim_...
--=3D[Live your life in the present, history will make itself in the future.]=3D--
http://www.winthrop.edu/~humphret
zzhumphreyt@winthrop.edu
Date: Tue, 29 Apr 1997 22:09:44 -0400 (EDT)
From: Figaro Tea <humphret@lurch.winthrop.edu>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re:(2) Porting+platforms+assembly, Modularization
On Tue, 29 Apr 1997, Allan Lund Jensen wrote:
> So I couldn=92t explain it to anyone else. Tim wants me to explain.=20
> Yep, just me, a rock and a hard place ;)
I didn't mean it, honestly:) I just wanted you tell me what you=20
understand so far.
> Here goes nothing:
> As I understand it, Tim, you=92ll avoid doing anything hardware-specific
> in the =91main=92 program. This will be done by hundreds of subroutines.
> These subroutines are in a way, selfcontained. They do not =91speak=92
to
> eachother on any level of the hardware, their interaction is entirely
> defined by the software (the language). Porting programs using this
> language requires no change of the =91main=92-program, but only to
the
> abovementioned subroutines. Since these routines are made for many
> different platforms, a program made in this language will run on all
> platforms. Improving programs is only a question of either a) optimizing
> the =91main=92-program b) improving the sub-routines (if you=92re really
> cool).
Yep, you pretty much got it. A few things though--I bet you knew that=20
was coming:)
1) Avoid using hardware-specifics around program modulariztion, the two=2
have absolutely nothing to do with each other. Program modularization is
abstract, and hardware-specifics, is, well, hardware-specific. Program=20
modularization could be taught without using any code to explain it, it's
a concept, a design technique.
2) I wouldn't necessarily say the routines are written for all platforms;
rather, I would word it like this: The platform specific code is=20
separated into its own module, porting to new platforms involves changing
just these modules--of course, if the modules themselves are written in=20
assembly then all the modules, in addition to the platform modules, would=
have to get rewritten.
What do you all think, does this sound like a bad design technique?
I=20
think it would benefit all programs that were written in this=20
fashion--except maybe for games that are starved for speed. If everyone=20
agrees that, at the very least, it's something worth considering and=20
discussing, I'd like to actually delve into how best to implement it. =20
All in favor...
P.S. All opposed can keep their mouths shut! Just kidding, you all can say a little bit too:)
..._Tim_...
--=3D[Live your life in the present, history will make itself in the future=.]=3D--
http://www.winthrop.edu/~humphret
zzhumphreyt@winthrop.edu
Date: Wed, 30 Apr 1997 02:31:23 -0500
From: Scott Lahteine <slur@world.std.com>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re: The General Thread
Very interesting topic indeed. [WARNING: OOP ahead]
I think we've all had fantasies about what we'd most like to
see in
a language. From this thread I see three fundamental desires:
1) The syntax should impose no restrictions.
2) The output should be small and fast.
3) Months of hard work should produce something reusable.
I programmed a couple of full-scale games for the Amiga in 68K
assembler way back when. I went straight to the hardware for everything:
sprites, blitter, sound, even the disk i/o.... After the first project
(which took two years part time to complete) I learned a valuable lesson
and created a general-purpose library of subroutines to build upon.
In the process I also generated a bunch of custom graphics formats
and had to make file conversion programs to go from IFF to my own. In the
process I ended up writing a general-purpose conversion program shell to
build upon.
The more productive I wanted to be the more generalized my code
had
to be. Once something had been fully tested and debugged it was tough to
jump in to implement a new feature - like support for a higher resolution
or more colors. Modularty helped, but commenting my code helped more!
Fortunately I was using DevPac, and the macro features were very
good, and it did a nice job with conditional assembly. I could use flags
to determine what kind of project would come out. With one line change
I
could re-assemble and get a whole different resolution or set of graphics.
I had to include a custom set of special debugging routines -
also
flaggable. Some to change the color of the screen so I'd know where a
crash was happening, others to print values in the corner. This kind of
thing is used in every language, of course.
From the whole experience I learned quite a bit about how design
translates into structure - or form follows function. Essentially I was
following an evolution of sorts. I never bothered to learn C in those days
because I was into the power and directness of assembly.
When I learned C this past year I was pleased to find it so easy
to
use. I was further pleased to discover the kind of output produced in most
cases was optimized in some very clever ways [ not unlike my own :) ].
With C at least I could see in my mind's eye a good facsimile of the
assembly beneath it and avoid doing things that would bulk up my code or
be
too time-consuming.
On the down-side the way that C uses stack-based parameter passing
and stack-based local variables is annoying to my assembly-loving side.
That kind of thing seems to me a very roundabout way of doing things. In
assembly we do things directly with registers - like it should be!
The C I've been using allows register-based parameter passing,
so I
don't feel too bad about that aspect any more. Because I have the option
of direct optimization by inlining assembly code I find C to be perfectly
acceptable for nearly all of the work I need to do.
Now I'm pursuing a course of intense C++ and OOP study, trying
to
get a sense of the way the language meshes with the design theory behind
it. I believe that all the essentials of design are encompassed by the
formalities of OOP in a way that most assembly programmers follow
intuitively in their methods but find restrictive in a syntax.
As for the kinds of restrictions that Figaro describes:
>>I just had a horrible battle with C++ about multiple
>>inheritance and classes: it pretty much wouldn't let me use functions
in
>>another class that I had written because it claimed they didn't
exist.
... RTFM to learn about "friend functions" and "scope."
The kind of modularity being described in this thread is already
in
existence, and we call it ABSTRACTION. Abstraction removes the user from
the pithy details of his lower-level implementation and allows him to
concentrate on the essential aspects of design. Any experienced assembly
programmer already applies this when he writes a subroutine called
DrawObject instead of inlining it.
The aspect of abstraction that troubles most low-level programmers
is "information hiding"(IH). [I mean, who am I hiding it from,
myself?]
This is what gives Figaro his troubles with accessing information across
classes. Information hiding means basically that you have very few
globals, and ideally none. Obviously this idea is very foreign to asm
lovers.
The other main function of IH is to make the program essentially
a
group of autonomous units that merely communicate requests to one another.
Instead of thinking always about "how am I gonna do this" the
programmer is
inclined to concentrate on interactions between objects. Hence, I can
simple say Garfield:Eat(foodAmount); and that's that.
Ideally a good asm programmer wants to jump into his code with
as
little planning as possible. We love the spontaneity of discovering tricky
new ways of doing mundane number-crunching. Unfortunately we often spend
so much time trying to trim a few bytes or save a few cycles that we do
TOO
MUCH optimizing in places that don't really require it. One word: PROFILER!
Ah, perfectionism is such a heavy burden....
I think the ideal language would perhaps be a mixture of OOP
with
the syntax of a theoretical processor (which, BTW, C is). An optimizing
loader could choose the best instructions for the target processor at
runtime. Modularization would be available as part of the syntax.
And of course you'd want to take a look at the output code and
be
able to give the compiler parameters to do similar cases in a better way.
(i.e., a compiler with an extendable expert system...)
As OOP matures, and perhaps as new languages emerge, I think
the
size & speed gap will necessarily shrink. I believe there will always
be a
need for good assembly programmers and we shouldn't worry over its demise.
Nevertheless, we should always be open to new languages. They were made
for us to enjoy!
-------------------------------------------------
Scott Lahteine <mailto:slur@world.std.com>
<http://world.std.com/~slur/>
"No Universe is perfect which leaves no room for improvement."
-------------------------------------------------
Date: Wed, 30 Apr 1997 02:32:35 -0400
From: Stuart Ball <lightsoft@compuserve.com>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: (3) Assembly as a true language
Robert C. Wagner wrote:
>I also seem to recall that there was some thought about using forth
for
>the brains behind plug and play cards (like PCI) as well, but I don't
>know if that was ever adopted.
Good point.
Yes it was adopted for the PCI boot. Details can be found in the white
paper I believe (which I don't seem to have anymore???).
Stu.
Date: Wed, 30 Apr 1997 02:32:38 -0400
From: Stuart Ball <lightsoft@compuserve.com>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Porting+platforms+speed
Tim wrote:
>Even in true assembly langauge you sometimes don't use all the
>processor's sexy instructions. Since I want my programs to work on
all
>Macs I only use 68020 instructions, if I wanted to use move16, a 68040
>instruction, then a lot of other Macs would be left out. The fact that
>in high-level assembly you can't use these sexy instructions isn't any
>different.
No, for speed what you'd do is find out what processor and system you
have
and use different bits of code optimised for said environment.
E.g. We have two screen splats - one 64 bit (stfd) and one 32 bit (stfs).
The 64 bit one runs some 20% faster than the 32 bit, if there is a 64 bit
video bus present. So you decide during init which is best for
compatibility and speed and then "hope for the best", err, I mean
"test"...
:-)
Stu.
>I believe there will always be a
>need for good assembly programmers and we shouldn't worry over its demise.
>Nevertheless, we should always be open to new languages. They were
made
>for us to enjoy!
Well said! Case in point: I've been doing some Perl programming lately
and it's tremendously fun.
James
Figaro Tea wrote:
> Yep, you pretty much got it.
EXTRA, EXTRA, READ ALL ABOUT!!
I was shocked, but also very happy, Allan explains to The Sun. I had
almost given up hope.
Todays top-story is the touching tale of a young mans fight to
understand the world around him. In an exciting, yet scary thread we
followed this debate through many days. After seven days, Figaro Tea
(The Man With The Plan) succeeded in making Allan understand a
shockingly simple idea. Sources close to Tea told this reporter that Tea
was, at one point, ready to give up.
Suddenly it became clear to me, Allan says, its a whole new way of
programming
This reporter also asked Allan about his connection with an unfortunate
incident involving six domestic animals, a rubber glove and a bottle of
tequila.
I have no comments at this time, says a slightly embarrased Allan,
that story is a complete fabrication. Besides it was a bottle of vodka
and a hedgehog.
Figaro Tea wrote:
> The switch from 68K to PowerPC wasn't that bad because both chips ran
> under the same OS.
Erm, they didnt actually. I used 68k on Amiga, and switched to PPC when
I got my Mac. Im slightly embarrased to admit it, but Im not really
into systems-programming. Ive read that most of the Macs OS is
written in Pascal and C, so it doesnt make sense to me to call
systemsroutine, if I can avoid it. This means, among other things, that
Id hate to use GWorlds, Windows, Menus or anything system-related. As
Scott Lahteine says, on the Amiga you didnt really want the system
around, so you kicked it out first chance you got. I know its not
pratical, smart or useful, but thats basically the way it is. I also
smoke ;)
> Allan, if you only ever write small snippets of code, then relearning
a
> new processor and writting the same program from scratch wouldn't be
all
> that burdensome; but for the programs that I'm writting, and will write,
> this is intolerable.
Ouch. Well, it is actually my plan to make more than just small
snippets of code. Wait and see...
> Well, maybe high-level assembly isn't your cup of figaro tea. Sad
> though, it hasn't even been created and you're already writting it
off.
Yeah, youre right, that wasnt fair. Maybe I will have that a cup of
figaro tea. As Ive said: its certainly a good idea.
Basically its all about different visions of the future. You say one
thing, I say the other.
However, *if* the future looks the way you say (no low-level assembler
and so on), Im sure youll be able to introduce me as the most
fanatical user at the press conference for your new, sexy language:
high-level assembler (Its not Java, its Tea!). I might be muttering
about the good ol days under my breath, but the hum of the cameras
should drown that out.
Allan
Allan wrote:
>EXTRA, EXTRA, READ ALL ABOUT!!
Cheers mate!
I've had a real *bad* day with the Modern Memory Manager messing me about.
(What were you saying about systems programming...)
The newspaper report was the funniest piece I've seen for a while (with
all
respect to Tim of course who I'm sure won't let you get away with it :)).
Cheered me up.
And admitting you *smoke* - in public too! Tut tut.
------
Anyway, a serious question.
Has anybody ever had the modern memory manager litterly "crumble"
on them?
I threw about two hundred locked handles at it today, and whilst no system
errors were reported (diligently checking memerr, reserr etc) things got
very
pear shaped. For example, CloseResFile would just hang. All this time I
had
about 300k free in the heap.
I reduced the number of handles, and things got better and better until
they
were back to normal at about 100 handles. At 130 handles, closeresfile would
work 50 percent of the time.
Struck me as being most weird and was indeed difficult to trace (eight
hours
difficult). Unfortunately I didn't have time to try it with the old memory
manager.
Anybody ever seen anything like this before?
Stu.
>Struck me as being most weird and was indeed difficult to trace (eight
hours
>difficult). Unfortunately I didn't have time to try it with the old
memory
>manager.
>
>Anybody ever seen anything like this before?
I've had cases when working with alot of handles that instead of moving
data inbto a new handle, it would move junk into the handle or nothing at
all. hmmm. strange.
----------------------------------------
Kevin Avila http://www.cache-computing.com
kevin@cache-computing.com
Date: Fri, 2 May 1997 00:53:08 -0400 (EDT)
From: Figaro Tea <humphret@lurch.winthrop.edu>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: An Informal Proposal for a New Programming Language
After much talk about the relative merits of assembly I feel that I'm
finally ready to state this:
Since all other languages suck, assembly is the only language that
deserves to exist.
Well, that was definately informal, wasn't it:)
Actually, I think that assembly language has qualities that are lacking
in other languages and that these qualities should be harnessed into a true
language. These qualities include, but are not limited to:
* minimal restrictions as to what the programmer is allowed to do
* simple instructions that allow any task to be accomplished with minimal
intrusion on the program's efficiency
Assembly language also has weaknesses in its present incarnation that
could be fixed by it becoming a true language:
* there are no standard instructions, which makes assembly language tied
to a particular processor and the code non-portable
Although true assembly language will never be replaced, since it offers
the only way of directly programming the processor and thus achieving
maximum program efficiency, the underlying methods used to program in
assembly should be harnessed into a true language.
This language won't be a true assembly language, but it should offer
the
advantages of it while being portable, i.e. it will be a *really* low
high-level language. This language should be so low as to be a "skin"
of
the processor, i.e. it hovers just enough above the processor so that its
instructions are almost the processor's instructions, yet it should be
high enough so that the language won't get damaged if the underlying
processor moves.
An example of this can be found from the assembly class I'm taking.
As
I've stated previously we program in SAL (Simple Assembly Language), move
on to MAL (MIPS Assembly Language), and finally to TAL (True Assembly
Language). TAL is the actual processor instructions, analogous to 68K,
PowerPC, x86, etc. Interestingly, MAL isn't the actual MIPS
instructions, although some of the instructions are, therefore MAL's
instructions have to be translated to TAL before the code can actually be
assembled. In MAL, the instruction,
mul $8,$9,$10
would have to be translated to the equivalent TAL instructions,
mult $9,$10
mflo $8
Some MAL instructions have direct equivalents to TAL instructions,
add $8,$9,$10
This new language would be similar in concept to MAL in that some of its
instructions might have direct equivalents and some would be synthesized
in as few instructions as possible. Note, that although in the example
above there was a true direct instruction translation, it might be
required to substitute a single, different, instruction; i.e.,
add $8,$9,10
to
addi $8,$9,10
Fantasm currently does this.
The difference between this language and other high-level languages is
that it will try as much as possible to emulate true assembly:
* It should take on the syntaxes and readability of true assembly
* There should be only one instruction per line
* "Registers" and memory should be the only things that can hold
data
It is my belief that straying from the restrictions and syntaxes of true
assembly will invite complexity into the language, thereby destroying the
benefit that it brings. At all times it should feel like true assembly,
complete with the headaches that true assembly language brings. The only
true benefit of the language will be a common instruction set, which will
make it portable across different processors.
The instructions of the target processor should be allowed in the new
language, with a caveat: the instruction should be flagged as a
violation of the language. Ideally, the editor itself would flag the
instruction as invalid, possibly by changing the color of the text of the
line the instruction appears on.
The instructions that will be used to translate from the new language
to
the processor language should be allowed to be changed. This is so that
if the programmer thinks they have a better translation, they can
implement it and in effect can tailor the language to their whims.
Similarly, the entire code produced by the new language should be allowed
to be edited, comments intact, so that the programmer can make changes to
only parts of the program and not necessarily the translations used.
Since programming languages are used by groups of people I think that
this new language should be defined and created by a group of people.
Since this is primarily an assembly list-serv what better place to create
an entirely new language. Allan's insistence that he wouldn't use a
high-level assembly unless he could get the speed of true assembly
prompted me to include the processor instructions as semi-valid
instructions. Since I'm only one person I can't think of everything, so
I would really want a group effort in creating this--that is if you
all want to do it. If need be though, I'll do it myself.
As for a name for this new language, I'm going to use what Allan said,
Tea. If someone can think of something better I'm open to suggestions.
P.S. Sorry for the semi-formal tone, but I'm serious about this and
I
really want this language to get developed.
..._Tim_...
--=[Live your life in the present, history will make itself in the future.]=--
http://www.winthrop.edu/~humphret
zzhumphreyt@winthrop.edu
Date: Thu, 1 May 1997 21:06:32 -0400 (EDT)
From: Figaro Tea <humphret@lurch.winthrop.edu>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re:(2) The General Thread
On Wed, 30 Apr 1997, Scott Lahteine wrote:
> I think we've all had fantasies about what we'd most like
to see in
> a language.
Quite right about that, of course you know what my desire probably is:)
One thing though, why not make it happen? Why live with an acceptable
substitute, especially if you have the ability to make what you really
want. Admittedly, you probably don't have the time and/or desire to do
it; but that's where visionaries like me come in--I mean you in this
sentence in a general way, and not you personally, Scott.
> From this thread I see three fundamental desires:
>
> 1) The syntax should impose no restrictions.
> 2) The output should be small and fast.
> 3) Months of hard work should produce something reusable.
I agree on points two and three, but not on one. Syntax will always
necessarily impose restrictions on *how* you do things, but not on *what*
you can do; i.e. you can always find a workaround. The point I was
bitching about in my C++ example, was that C++ made it so that I had to
do things its way, sometimes flat-out preventing me from doing some
things. Being an assembly programmer I often do theoretically bad
things, like adding a char like it was an int, but these things do no
harm and makes some tasks easier. I don't like langauges that impair my
ability to do what I want simply because they won't let me--assembly may
make some tasks hard, but I can *always* find a way to do the task.
> I believe that all the essentials of design are encompassed by the
> intuitively in their methods but find restrictive in a syntax.
From this list-serv I've learned that macros are very powerful tools
that
can greatly enhance a program. I see the problem that you're stating
with assembly syntax and OOP: and I see a solution in macros. Using
macros you can easily pass all the data that needs to be tediously and
laboriously passed. You can take it a step further by combining them with
subroutines. I get specific types of data from a window by passing to a
macro a window pointer, this macro is simply two lines which sets up
register D0 and calls a subroutine to do the data retrieval: I use the
macro to do all the tedious setting up of registers, and I use the
subroutine to implement the task and to save me some space.
> As for the kinds of restrictions that Figaro describes:
>
> >>I just had a horrible battle with C++ about multiple
> >>inheritance and classes: it pretty much wouldn't let me use
functions in
> >>another class that I had written because it claimed they didn't
exist.
>
> ... RTFM to learn about "friend functions" and "scope."
I'm email deficient in that I don't know what RTFM means, but... I do
know about friend functions and scope, I just didn't want to make an
entire class friendly just so I could use its functions--kinda defeats
the purpose of inheritance.
> The kind of modularity being described in this thread is already
in
> existence, and we call it ABSTRACTION. Abstraction removes the user
from
> the pithy details of his lower-level implementation and allows him
to
> concentrate on the essential aspects of design. Any experienced assembly
> programmer already applies this when he writes a subroutine called
> DrawObject instead of inlining it
What you said later on, about information hiding, is more of what I'm
talking about; the pure abstraction you're describing isn't. I use a
routine called DrawIcon to draw an icon at a specific point on the
screen, thereby abstracting from dealing with the actual implementation.
However, this DrawIcon routine could still deal directly with another one
of my routines. This goes against what I've been saying about modules,
subroutines, being separate, and goes for what you've said about
information hiding.
> The aspect of abstraction that troubles most low-level programmers
> is "information hiding"(IH). [I mean, who am I hiding it
from, myself?]
> This is what gives Figaro his troubles with accessing information across
> classes.
I would hardly call classes low-level; if they were then I wouldn't have
any trouble with them. The *concept* of classes is independent from the
way C++ *implements* them. So, no, I don't have a problem with classes,
just C++.
> Information hiding means basically that you have very few
> globals, and ideally none. Obviously this idea is very foreign to
asm
> lovers.
I'll have to give you credit here. This idea was foreign to me until
sometime last year.
> The other main function of IH is to make the program essentially
a
> group of autonomous units that merely communicate requests to one another.
Exactly what I've been talking about with program modularization.
Something that just occurred to me was that I've been separating the
concepts of OOP from any particular language implementation of it. This
came to me when you said that assembly programmers have a hard time
dealing with this. OOP/program modularization are concepts that can be
implemented in any language.
I would still like to see program modularization studied further. I
don't necessarily mean discussing the things that are discussed with
OOP, although I wouldn't mind this; rather, I want to find a design
philosophy. You know the way that most organisms have systems:
circulatory, respiratory, digestive, nervous, etc. I want to find a, more
or less, common way to program. For instance, while making Budding
Animator I've noted a couple of things that would probably have to be in
every program made:
1) You need to interface with your host system. This takes the form
of
OS calls and such. I doubt that unless you program in assembly you have
to worry about this too much.
2) You need to build an application shell. This is the interface that
you have with the user. A program will do something, but it needs a way
to communicate that something with the user, the application shell is the
way. This also goes back to #1, interfacing with the system.
3) You do whatever it is that you do. You communicate this activity
through the application shell, and it in turn falls back on the OS.
This is the kind of thing that I want to talk about: exactly what does
it
mean to design a program? How do you do it? What does it require? Since
I'm still at #2 with Budding Animator I haven't gotten much into other
aspects of programming. For instance, #3 encompasses a lot, I'm sure it
can be further broken down and analyzed...
P.S. Whoever first picks up the topic just discussed, program design
philisophy, please change the thread name to reflect what it's about.
..._Tim_...
--=[Live your life in the present, history will make itself in the future.]=--
http://www.winthrop.edu/~humphret
zzhumphreyt@winthrop.edu
Date: Thu, 1 May 1997 22:15:02 -0800
From: Kevin Avila <kevin@cache-computing.com>
To: Multiple recipients of <list-fantasm@mail.tau.it>
Subject: Re: An Informal Proposal for a New Programming Language
>Actually, I think that assembly language has qualities that are lacking
>in other languages and that these qualities should be harnessed into
a true
>language. These qualities include, but are not limited to:
> * minimal restrictions as to what the programmer is allowed to do
> * simple instructions that allow any task to be accomplished with minimal
> intrusion on the program's efficiency
Tim, there is already one. It's called ECL. :) Download it from the
lightsoft pages. It works wonders.
----------------------------------------
Kevin Avila http://www.cache-computing.com
kevin@cache-computing.com
Date: Fri, 2 May 1997 00:53:40 -0400
From: Stuart Ball <lightsoft@compuse