18D. Amiga E FAQ
----------------
[94_10_1..94_12_1]

This FAQ-list (Frequently Asked Questions) was compiled by looking through
old email and gathering those questions which keep popping up.



Compiler/Linking/Executables

- Will EC generate code for PowerPC Amiga's, if they become available?

  Likely, though don't pin me down on this. I have an idea on how to
  adapt EC for PPC, and maybe other processors/languages as well.
  When, where and how this is going to happen depends, and you'll just
  have to wait. A project like this easily requires a year's worth
  of hard work, so if I'm to go through with it, it'd better be worth it.
  That of course depends heavily on the future of the Amiga.

- How can I link E code with other languages? / use standard object (.o) format?

  Converting between .m and .o really isn't a huge problem, as one can see
  from the o2m utility, which allows cooperation between E and Macro-Assembly
  quite marvelously. The problem with C is in the compiled code, not the file
  format. Anything but trivial C will reference things like _DOSBase, link-
  library functions, stack-bases or other things from startup-code that E
  provides in a quite different way, for example E's startup code is very
  different from that of C compilers, and dosbase in E is placed on the stack,
  not in the exe as with C. Even two C compilers may have these problems.
  If you can get your C compiler to deliver a .o without external references
  etc., you can link it with E (I did this once with MaxonC++). If you need
  to program a project in both E and another language, you may wish to look
  at E's (or the other language's) library linking facilities. E is really
  quite a bit different from other languages (e.g. C), and providing .o
  linking facilities only makes sense if the code contained in the .o
  files can cooperate, which isn't the case with E.

- Can I link amiga.lib?

  Currently no. To a lesser extend this has the same problems as .o files.
  Many functions from amiga.lib have already been "converted" to E modules.
  (see

- Can E code be made resident?

  Nearly ALL E code is already resident-able without the help of the
  programmer. As fas as I know, the only E construct that can violate this is
  a static list [] with an expression in it (so [a], for example. [1] or
  NEW [a] is ok.).

- I have this application with pieces of inline asm, and after
  OPTI/S it behaves weird. what is going on?

  Inline asm may use the same registers as the register optimizer does.
  check E.doc for this.

- I wrote X in both C and E, and the E version is Y times slower/faster.
  how come?

  It's not easy to compare both in a fair way. Often it may be the case that
  one of the two has more optimized routines for something (string handling,
  I/O etc.). Use of a profiler can reveal this. If the code in question only
  does calculations, there's no reason why any of the two should be
  significantly slower than the other, if used properly.

- I have written this nice 'myutils.m', only when I use one function
  from it, EC links all. I don't like that.

  The style of writing modules in E is to keep them as relatively small units,
  with only related code and data. (This makes more sense if you know that the
  module is the unit of datahiding in E). Split it up!

- Can I make EC resident?

  no, currently not. EC itself is still written in old-fashioned assembly
  style, and cannot be made resident ;-)

- Can we have an option for EC to generate assembly source instead of an
  executable?

  No. There's no intermediate level of assembly in EC, it generates code
  directly. Using a disassembler is as close as you will get.

- I have been disassembling some code generated by EC, and I think this
  bit of code here can be optimized to this bit of code.

  Sure it can, I can see that too. But EC is not an assembly programmer.
  Doing really very high quality optimisations would require a complete
  rewrite of EC, and would make it a lot slower, even with optimisation off.
  Writing a good optimizer for a compiler is quite a non-trivial operation,
  and if some EC generated code is sub-optimal or downright silly doesn't
  mean I must be amateur assembly programmer too, and you need to explain me
  how its done.

- E should have a CHIP keyword or somesuch, to put data areas in chip memory.

  I don't find this worth it. If the amount of data is small (a gadget image),
  it's no waste doing a CopyMem(). If it's large (an iff picture, a sample),
  what's it doing in the executable in the first place? load it directly to
  chip mem from disk.


Resources

- There's no explanation in the docs of all those handy functions from
  intuition.library etc. How come?

  The functions are not part of E, rather they are part of the amiga OS.
  As such, they are described by Commodore's documents, not by the E documents.
  "The AMIGA ROM Kernal Reference Manuals" are a series of books published
  by Addison Wesley. A good place to start is for example "Libraries", ISBN
  0-201-56774-1. Other books are worth considering too, an example is "The
  Amiga Guru Book" by Ralph Babel. All the C code you come across in the
  RKRMs is available in E form in Src/RKRM/

- I'd like to read more source code than what comes with the distribution
  where should I look?

  There are lots of places too look, but the best is without doubt Aminet
  (A collection of FTP-sites on the internet), for example ftp.luth.se.
  In the directory 'pub/aminet/dev/e' you'll find all sorts of E related
  stuff. Some BBS'es outside of the internet also carry Aminet, and there
  are even CDROMs available. Another good place to pick up sources and
  to talk with fellow E programmers is the E mailing list. Send an email
  with 'SUBSCRIBE' in the subject to 'amigae-list@intercom.it' (or
  'UNSUBSCRIBE' if you want get off it again), and any future messages to
  the same address. If you have any problems with the list email
  'fsoft@intercom.it' (Fabio Rotondo, the list administrator). The old list
  at amigae-request@bkhouse.cts.com is no longer operational.
  There are E discussion on other nets as well (FidoNet, AmigaNet),
  public domain disk series (EPD in europe/germany, same address as the german
  registration site), furthermore there are heaps of user-clubs, BBS's etc.
  supporting E these days. just look around in your area.

- I have troubles understanding your incomprehensible english. Can I read
  about E in my own language?

  There are translations of E.guide (some older versions) in german, french,
  spanish and italian, the first three are available on Aminet.

- Where can I find any E related sites on the WWW?

  You can take my home page (http://ecs.soton.ac.uk/~wvo96r/) as a starting
  point. it has an E homepage which has links to a few other E sites.

- I have heard about this mailing list. is it any good?

  Find out for yourself. If you're serious about E it's definitly a must, also
  because it's the place where news on E is generally released first.
  Many good E programmers are on it as well, so you are sure to get the
  right answers to your questions.

- I have a hard time getting on the mailing list. Could you take care of that
  for me?

  I personally don't have anything to do with the administration of the list,
  so I can't help out any better than anyone else can. Remember that the
  server is an automated process, so you need to be very precise in what you
  send there. Don't send administrative post to the list at large, instead
  try and get hold of the administrator (Fabio Rotondo: fsoft@intercom.it).

- I'm new to internet. Could you help me get on the mailing list /
  FTP files from Aminet etc...?

  Stuff like that is way beyond my service. Please try and contact someone
  locally.

- How do I know what is the latest version / How do I receive it?

  If you're on the mailing list you'll be the first to know. Aminet is the
  place where releases and updates are uploaded first.

- Can you send me email as soon as a new version is out?

  No. I used to send all registered users email with new versions, but can't
  do so anymore as the number is too large (last time I tried I jammed our
  network and crashed various workstations).

- How do I register?

  please read E.doc on this.

- Does E exist for other platforms?

  Not Yet. Personally I have undertaken small projects to make portable
  compilers/translators, and several others have E compiler projects on other
  platforms, but nothing has come out of this so far.
  Portability of some form might be available as a spin-off of the PPC
  backend project (see

- Can I become an E registration site for country X?

  Generally I pick sites myself, when I feel the necessity, and know someone
  in that country pretty well.

- Can I start an E support BBS / an E programming club...?

  You can always do that, without asking me. I of course enjoy hearing about
  efforts like this...

- Just out of curiosity, how many registered E programmers are there?

  This changes all the time. Inquire within :-)


Programming

- Can I do X in E? (where X = {games,dtp-packages,...})

  E is a general purpose programming language, so there shouldn't be any type
  of program that can't be done in E (with few rare exceptions, which are covered
  by E's inline asm). This doesn't mean E is especially equipped for certain
  types of programs, i.e. E has no special functions for games (though its
  extensibility makes it easy to add them).

- How do I create X in E (where X = {window, interupt handler,...})

  as with the last question, E just opens the possibilities to write anything,
  and there isn't always a specific function available. In the worst case this
  means having to use difficult functions from spooky libraries, but it's
  worth it getting to grips with that. If you're lucky some E programmer
  already has done something similar which you can learn from.

- Please write me an example how to do X in E.

  Please try to figure it out yourself first, or ask other E programmers to
  help out.

- The compiler refuses to compile things like myscreen.rastport.bitmap,
  eventhough x.y.z is generally possible. Why is that?

  Thanks to jasons v40 modules this should not be a problem anymore.
  The only case where this can still occur is if you do not include the
  module that defines the object "z" is in.

- I'm writing code like this:

	DEF s[100]:STRING
	s:='my beautiful string'

  which is allowed by the compiler, but later gives me problems. What can possibly
  be wrong with this?

  If you're used to for example BASIC, you're used to handle strings in the
  same way as integers, as they are both _values_. In E however there are no
  real string variables in the BASIC sense, the DEF above creates a piece of
  memory to hold a string, then sets the variable as a pointer to this memory.
  The pointer and the memory are implementation-wise two unrelated entities.
  From that DEF on, all operation that directly access 's' access the pointer,
  which is just an integer which tells us were to find the actual string.
  The assignment thus puts the address of 'my beautiful string' into 's',
  overwriting the old value. The string-memory created by the DEF sits there
  unaltered, and now unaccessable because no pointer points to it. Functions
  like StrCopy() can use this pointer to find the real memory, and can fill
  it:

	StrCopy(s,'my beautiful string')

  is correct. Of course assigning strings as pointers also has a use, for
  example if you just want to read the string data and do nothing else with
  it. then:

	DEF s:PTR TO CHAR

  allocates no memory for a string, only the pointer. the assignment above
  would now make sense. This all boils down to the differences between
  pointers and values (or value/reference semantics), and is important to
  understand to succesfully program in E.

- How do I return a STRING / OBJECT etc. from a function?

  depends. If you just wish to use it as temporary return value, give a string
  as argument and let the routine fill it. If you need to create a NEW string/
  object, allocate it dynamically within the function, and return the pointer.

- can I create an array of typed pointers, eg ARRAY OF PTR TO LONG

  um... no. you'll have to use an ARRAY OF LONG instead.


<more of these specific questions are to be added>



Bugs

- I remember programming something when suddenly the compiler crashed/
  misbehaved/produced an internal error/gave wrong error messages. shouldn't
  you be doing something about this?

  If I have no clue where to look for a bug I can't fix it. If you stumble
  across something that you're sure of is a compiler bug, make a copy of
  the source that reproduces the bug (possibly cut the source down while
  making sure it still shows the bug) and send it to me with as much info
  as possible. EC-enforcer hits for example are very useful.

- I wrote program X, but it crashes. I'm positive I made no mistakes,
  so certainly this must be a compiler bug.

  due to E's untyped-ness, you can never be quite sure you're code is
  correct. Most code send to me with comments like the above later proved
  to be errors in the code, mostly due to lack of E knowledge. Read the
  docs, and use EDBG!



Future Features

Will E have...
- Initialisation for globals in modules?
- Unaligned object members?
- Bitfields?
- Startup code that doesn't open intuition etc.?
- A feature to automatically include all modules used by a module?
- Access to object members in methods without the `self.' prefix?
- DEFs halfway PROCs or local to loops etc.?
- Disassembly mixed mode for EDBG?
- Sourcecode level #include?
- Unsigned INT/LONG or signed CHARs?
- Multiple statements in macros?
- Multiple error messages?
- Dereferenced variables in lefthandsides of assignment expressions,
  multiple returnvalue assignments, and the {} operator?
- Inlined code for small functions (e.g. Shl())?

No. Or atleast very unlikely.

- Registerised arguments?

  It surely is possible but like many things it's not a priority for me.

- Library linker?

  Yes, it's included in this version.

- Multiple Inheritance?

  Not possible in E. MI breaks with structural compatability between objects,
  and needs relatively strong typing to resolve this.

- PROCs inside PROCs?

  Not likely.

- multidimensional arrays?

  Not likely either. In E there isn't really something like an array, just
  pointers that point to a large amounts of equally sized objects. To have
  twodimensional arrays, one needs to have the concept of 'size' of an array,
  which E doesn't have.

- Overloading

  No. Overloading requires quite strong typing to distinguish which function
  to call. Besides, overloading is 100% syntactic sugaring, it doesn't provide
  any added functionality whatsoever.

- more 020/881 support?

  Yes, eventually. It just isn't at the top of my TODO-list.

- assembly source output?

  No. Unlike other compilers, E never passes an assembly stage, E code is
  compiled directly to opcodes. Providing this feature would boil down
  to doing a disassembly. E's inline assembler is not used for generating
  code for E constructs. (see

- C compatible syntax?

  Often people are used to some type of language (mostly C), and don't
  understand why a programming language design isn't as configurable as a
  directory utility or text editor:
  'I like "=="/"=" better than "="/":="'
  'Can't you switch """ and "'" ?'
  'Why doesn't "--" work as in C?'
  'I hate typing CAPS for keywords!'
  'No precedence sucks!'
  The features 'referenced' above will never change, and you'd better get use
  to them. All design decisions have good reasons, and unlike some rumours
  they were not done for compiler speed (infact implementing them more
  traditionally wouldn't make the compiler any slower).

- Why is feature X in E not like language Y, which I find better.

  Like above, the design of a language isn't changed just because of
  personal preference. If you have strong ideas of what a language should
  look like according to you, and those ideas stem from language Y, then
  use Y. If you can't find your ideas in any existing language, then it's
  time to design and implement your own! (I'm not kidding, it's worth the
  trouble! and you can always start with E... :-)

- X maybe?

  Having seen literally hundreds of programming languages, your chances of
  suggesting a new feature for E which I haven't thought of before are not
  too bright. Many things don't 'fit' into E, and in general time is limited
  to add more fancy stuff. (If you look closely, the amount of features in
  E is already quite high for an average programming language). I have quite
  a huge list of possible features for E, and eventually some of these will
  be implemented. just wait and see...