meta A new language for the Atari

[ivop]

5 minutes ago, sanny said:

I see and in general agree with you. But changing this now changes behaviour as it was for the last 20 years. It's difficult. I don't want to piss off people because their program suddenly behaves different.

Yes, it's difficult. Changing expected behaviour is not something you want. And if all the CC65 targets do the same, probably leave it like that. Exporting the __LMARGIN symbol is probably the way to go, so a userspace program could set it back to what it was before calling the program.

 

5 minutes ago, sanny said:

I disagree. If there are command line arguments I want to have them in argc/argv and don't care how they ended up there,

Agree. Should have been clearer. My remark was referring to Kaj's new compiler adding code to detect whether it was called from a command line DOS or not. That's not the job of a compiler.

[drac030]

23 minutes ago, sanny said:

But changing this now changes behaviour as it was for the last 20 years. It's difficult.

Might it be possible to just add a compile switch -DCRT0_OLD or so and get away with it?

[ivop]

20 minutes ago, drac030 said:

Might it be possible to just add a compile switch -DCRT0_OLD or so and get away with it?

Good idea, although I would do it the other way around. Keep standard behaviour of 20+ years the same, but add -DCRT0_NEW or something.

 

[Wrathchild]

A define passed to your client build isn't going to affect a built object/library?

sanny's first suggestion to restore it seems fine.

[sanny]

Hmm. You mean when compiling cc65? There are already compile-time options, see libsrc/atari/Makefile.inc.

 

# NUMDRVS        - number of supported drives (max. 16)
#                  4 bytes for each device are statically allocated
# LINEBUF        - support line buffered reads from E: (the number specifies
#                  the length of the buffer)
# UCASE_FILENAME - all filenames get uppercased
# DEFAULT_DEVICE - if the string passed to the uppercase function doesn't
#                  include a device (":" at position 2 or 3), provide "Dn:"
#                  as a default disk device
#                  n is the value of DEFAULT_DEVICE, unless DYNAMIC_DD is
#                  also set, in which case it's overridden by a runtime
#                  check (on SpartaDOS only)
#                  needs UCASE_FILENAME to be defined, otherwise no effect
# DYNAMIC_DD     - determine default disk device at runtime (SpartaDOS only)
#                  needs DEFAULT_DEVICE to be defined, otherwise no effect

CA65FLAGS += -D NUMDRVS=4 -D LINEBUF=80 -D UCASE_FILENAME=1 -D DEFAULT_DEVICE=1 -D DYNAMIC_DD=1

# The following defines are only used by the 'atarixl' target:
#
# CHARGEN_RELOC  - If defined, CHBAS and CHBASE are updated when
#                  enabling or disabling the ROM.
#                  If the ROM is enabled, $E0 is written to CHBAS
#                  and CHBASE.
#                  If the ROM is disabled, the upper byte of
#                  __CHARGEN_START__ is written to CHBAS and CHBASE.
# USEWSYNC       - If defined, the code waits for horizontal retrace
#                  before switching the ROM and updating CHBAS and
#                  CHBASE. This define only has effect if CHARGEN_RELOC
#                  is also defined.

# Disabled by default, you should enable it if the linker script relocates the
# character generator (like atarixl-largehimem.cfg).
#CA65FLAGS += -D CHARGEN_RELOC -D USEWSYNC

# Disable if you don't want to use page 6 for mouse P/M data.
# If disabled, top of the RAM is used for P/M data.
CA65FLAGS += -D USE_PAGE6

 

So, adding another knob would be OK for me.

[drac030]

Not exactly, I meant the switch when compiling a program, so that one could define in a Makefile if the "portable" behaviour is desired or not. And the switch would of course be rather for the linker to pick the proper version of crt0.o when linking everything (if this is how this works in cc65, I have no idea, TBH).

 

I do not like the idea of "restoring", because this way still my console settings (when running the program compiled in cc65, that is) depend on whether a programmer on the other end of the world is able to know that he should restore that, or remember how to do that correctly etc. It would be best to leave this setting as is, as it was already said it is external environment which a program should accept, and modify only when there is absolute must.

[ivop]

30 minutes ago, sanny said:

Hmm. You mean when compiling cc65?

No, like drac030 says, it's a command line option when compiling something with CC65. Like how glibc has a gazillion ifdefs which are resolved at run time when the preprocessor runs through all the files. Current behaviour should be default, but a plain crt0.s without fiddling with the console would be nice if that got upstream.

 

#ifndef __CRT0_NEW

// current stuff

#else

// minimal setup for CC65 ABI

#endif

 

[sanny]

25 minutes ago, drac030 said:

Not exactly, I meant the switch when compiling a program, so that one could define in a Makefile if the "portable" behaviour is desired or not. And the switch would of course be rather for the linker to pick the proper version of crt0.o when linking everything (if this is how this works in cc65, I have no idea, TBH).

 

That's not possible in the current cc65 "make environment". There's just one crt0.o.  You can of course always modify the crt0.s file and link it with your program.

 

25 minutes ago, drac030 said:

 

I do not like the idea of "restoring", because this way still my console settings (when running the program compiled in cc65, that is) depend on whether a programmer on the other end of the world is able to know that he should restore that, or remember how to do that correctly etc. It would be best to leave this setting as is, as it was already said it is external environment which a program should accept, and modify only when there is absolute must.

 

I don't understand. "restoring" to me is just restoring the settings (e.g. LMARGN) as they were before.

[drac030]

1 minute ago, sanny said:

I don't understand. "restoring" to me is just restoring the settings (e.g. LMARGN) as they were before.

Let us say that I set my LMARGN to 3. I want programs to display stuff on the console with that margin.

 

But someone in, say, Polynesia writes a program to list directories, then publishes it in binary form as LISTDIR.COM. He has no idea that he has to "restore" anything before listing a directory, besides, his favourite LMARGN is 0, so he is not even able to see any problem here.

 

But on my system his program, when executed, will list directory at column 0, because that is what crt0 does behind backs of everyone. It does not help much that the program will (also behind the backs of everyone) restore the original settings before quitting: on my system it will still print the directory at the WRONG column of the screen.

 

[sanny]

I don't understand what you want to tell me.

 

Restoring (to the previous setting, 2 by default) LMARGN is possible with the latest cc65 change.

[Kaj de Vos]

Nice to see the engagement. ?

 

2 hours ago, ivop said:

Agree. Should have been clearer. My remark was referring to Kaj's new compiler adding code to detect whether it was called from a command line DOS or not. That's not the job of a compiler.

I agree that it's problematic, that's why I didn't want to add it at first, and that's why I'm only compiling it in when it's clearly needed.

 

My own use case is a command-line DOS, where it's not needed and thus overhead. But most people use a menu DOS or, these days, run a program straight from an emulator. It wouldn't be a bad idea for the emulators or even menu DOSes to do the wait for a key press, but they don't. This forces every programmer to do something like it in every program. That makes them annoying to use from command-line DOSes. At the same time, programs from programmers on command-line DOSes will usually not do it, so they will be unusable from menu DOSes and emulators. And when my language just generates command-line style programs like other languages, I will set up almost all new users for a bad experience.

 

This is quite bad. If the environment doesn't take care of running all programs properly, the programs will have to do it themselves, and probe the environment. Also keep in mind that REBOL languages aim to be user-friendly. And a goal of the project is to unite all platforms, not to divide them. I want to produce programs from a single source that run well in all environments. It's a question of defaults. If an option makes an entire class of programs work better, it should be the default. If an option makes an entire class of programs worse or impossible, it should not be the default.

 

Note that this will not be cut in stone: I will provide an option to not add the code when a program requires it, for example if someone wants to localise the message. And there will be compiler modes for libraries and for drivers, where this code will obviously not be compiled in.

 

REBOL has quite a few places where it tries to be just a little too smart for its own good. These range from annoying to disastrous, so I know what you mean. That's why I also take quite a bit of inspiration from C. I want the language to be as elegant, user-friendly and high-level as REBOL, but with the openness and performance of C. This is indeed one of those cases where it could go wrong, so it needs to be designed very carefully.

[sanny]

Yes, this clearing of the screen of "menu-DOSes" is annoying. Workaround in cc65 is something like that (at the start of main()?

 

#ifdef __CC65__
    /* If DOS automatically will clear the screen after the program exits,
    ** then wait for a key-press.
    */
    if (doesclrscrafterexit())
        atexit((void (*)(void))cgetc);
#endif

 

[Kaj de Vos]

That's roughly equivalent to what I compile in. ?

[drac030]

11 hours ago, sanny said:

Restoring (to the previous setting, 2 by default) LMARGN is possible with the latest cc65 change.

Yeah, the author of the program can explicitly restore. What if he does not do that? Then the settings will be wrong on user's console during the program's execution. That is the point.

[Kaj de Vos]

Most C programs are cross-platform, so the author will never know that an action is required on an Atari for normal operation.

[sanny]

7 hours ago, drac030 said:

Yeah, the author of the program can explicitly restore. What if he does not do that? Then the settings will be wrong on user's console during the program's execution. That is the point.

 

If he doesn't restore he doesn't care. Not my problem. I gave the knobs to change it.

 

I consider the cc65 default of setting LMARGN to 0 good, because I want a 40x24 screen, not a 38(or whatever)x24 screen. And in the sense of cross-platform, that's the resolution of many other targets (ok, 25 lines and not 24 there).

[sanny]

3 hours ago, Kaj de Vos said:

Most C programs are cross-platform, so the author will never know that an action is required on an Atari for normal operation.

 

Which "normal operation"?

[Kaj de Vos]

A common class of cross-platform programs is command-line programs. They use the abstracted stdin, stdout and stderr I/O and have no notion of margin or other console settings.

 

I do agree that S: access (so conio.h) should best be 40x24 for cross-platform, but not E: access.

[dmsc]

Hi!

 

IMHO, the setting of LMARGIN this should be discussed in the CC65 issua tracker  . My take on this is that usage of any conio function should add the code to the initialization, but it should be skipped if no conio function is called. This is possible by adding it as constructor and destructor. Also, the code to set the LMARGIN at start (and save the original value) should be moved to the ONCE section.

 

Have Fun!

[dmsc]

Hi!

On 3/31/2021 at 2:07 PM, Kaj de Vos said:

The margin is a user setting in the external environment, that a toolchain should not mess with, so I needed to get rid of this. I found it deep in CC65 in crt0.s. To change it, I needed to remove my CC65 installation and install it from source. The instructions for this have disappeared from the CC65 documentation. My language now requires a patched CC65.

 

You don't need to do this, to use a custom crt0.s file just include the new crt0.o file in the linker command line, it will take precedence over the one included in the library.

 

Have Fun!

 

[dmsc]

Hi!

On 3/31/2021 at 9:34 PM, Wrathchild said:

I think I read the @dmsc was adding a build to Fast Basic distros but (I'll let him confirm) I believe that was in order to simply use a known/given release of CC65 with FB and not a variant?

 

Yes, main reason is to allow using the last version of the tools included in the release - people tend to install really old versions that don't support all the features needed for FastBasic.

 

The other big win is to be able to compile and run the tests without needing to first install CC65, and to also distribute only the needed tools: CA65, LD65 and AR65.

 

Have Fun!

[funkheld]

why is another language being developed here that almost exists and is nothing new.

I had already written once that the freshness is missing with rs232 and tcp.

the other is only a partial copy of what has already been created.

 

greetin

[Kaj de Vos]

Ah, the famous Why? question. In short: because I need it, and I hope others will find it useful, too. See the start of this thread.

 

I suppose you are referring to REBOL? It doesn't run on 8-bit. REBOL and Red are touted as very small: one executable under one MB. Red's graphical version has grown over that by now. That doesn't exactly fit in an 8-bit. REBOL's smallest target used to be Amiga, but those times are long past. REBOL started with more than fourty target systems, but REBOL 2 lost targets over time until only the few modern systems were still supported, and the graphical version eventually only ran well on Windows. REBOL 3 can be built from source for Amiga again, but there only are binaries for modern systems, and no graphical version. Red targets even fewer systems so far, and not even modern 64-bit systems, that almost everyone uses now. My language can target 8-bit, and as we just established above, a small Hello World program is 1.5 KB, with room for improvement in the future. On 64-bit Linux, it's currently 16 KB.

 

I'm working on a few benchmarks, but I can already reveal that the language is a few hundred times faster than REBOL and a few thousand times faster than the Red interpreter.

 

This performance is common for the classic mid-level languages such as C and Pascal. But for the REBOL language family, it's revolutionary. It should be a game changer in the REBOL world, making a REBOL language competitive with those other languages. It will also be a game changer for the REBOL scene on small systems, because they can now have it for the first time. Compared to other languages, it will have all the advantages of REBOL: higher expressiveness, more user-friendliness, more cross-platform abstraction, smaller complexity, more productivity, more joy. Things that no other language design combines.

 

We are also shaking out issues in parts of the Atari eco system. That's not a bad thing.

[danwinslow]

9 hours ago, dmsc said:

Hi!

 

IMHO, the setting of LMARGIN this should be discussed in the CC65 issua tracker  . 

 

Have Fun!

i agree.

[ivop]

Why don't you target the 6502 directly? 1.5kB for Hello World is pretty big IMHO. In assembly or Action! or Basic, that's way smaller.

 

I understand you want a C backend to quickly cover every platform that has a proper C compiler, but I doubt that's the right direction for 8-bit platforms if you want to compete with C itself, or Mad Pascal, or ....

 

If you want your new language to gain any relevance, I would try an LLVM backend for current machines, and direct assembly output for oldskool 8-bit computers.