linux support

[brucee]

>
> cat program.bas quit.bas |sed -e's/\x27.*$/\/\//' |cpp -nostdinc -I
> basic_lib_dir - - |cat vectors - |ARMbasic > program.hex
>

there were two mistakes in my previous post:
(1) we should only replace ' (\x27) not the ' to end-of-line (\x27.*$)
(2) after running cpp we have to restore the "surviving", i.e.
non-comment ' characters; for instance those contained in literal
string constants.

fortunately, the ARBbasic help file states that the compiles only uses
ascii characters within the range 0x20-0x7E (inclusive; except for at
least \n, obviously) such that characters outside this range should
not occur in valid basic source. but they could be abused as markers
for substituted ' comments. since cpp handles those characters
transparently (at leat under linux/unix), we can reconstruct
non-comment ' characters after the cpp run. i picked DEL for the code
below as this seems unlikely to interfere with other things in the
text source but other "control characters" should work as well.

here is a better version
to include the preprocessor step:

cat program.bas quit.bas |sed -e's/\x27/\/\/\x7F/' |cpp -nostdinc -I
basic_lib_dir - - |sed -e's/\/\/\x7F/\x27/' |cat vectors - |ARMbasic >
program.hex


One more suggestion:
the command line compiler ARMbasic should exit with a non-zero exit
code if the program did not compile without errors. this would greatly
simplify error detection before trying to upload the compiler output
to the hardware.

[brucee]

> cat program.bas quit.bas |sed -e's/\x27/\/\/\x7F/' |cpp -nostdinc -I
> basic_lib_dir - - |sed -e's/\/\/\x7F/\x27/' |cat vectors - |ARMbasic >
> program.hex

I wish it was that easy, but all the included files have to be
processed, and the way that happens now is BASICtools starts with the
"main" source, strips all the commands and looks for any #includes.
The output file is placed into a temp directory without comments and
the paths for the #include changed. Then each #include file found is
also stripped and placed into the temp directory....

Then cpp can be run on the processed files in the temp directory.
This Tcl script could and probably should be isolated from BASICtools.

> One more suggestion:
> the command line compiler ARMbasic should exit with a non-zero exit
> code if the program did not compile without errors. this would greatly
> simplify error detection before trying to upload the compiler output
> to the hardware.
>

Easy enough to add, and it will be.

[brucee]

>
> > cat program.bas quit.bas |sed -e's/\x27/\/\/\x7F/' |cpp -nostdinc -I
> > basic_lib_dir - - |sed -e's/\/\/\x7F/\x27/' |cat vectors - |ARMbasic >
> > program.hex
>
> I wish it was that easy, but all the included files have to be
> processed, and the way that happens now is BASICtools starts with the
> "main" source, strips all the commands and looks for any #includes.
> The output file is placed into a temp directory without comments and
> the paths for the #include changed. Then each #include file found is
> also stripped and placed into the temp directory....


i modified cpp to treat ' basic line comment the same way as the
original cpp treats c++ style // line comments and uploaded some
(very alpha) code into the files section.

i was not so happy with the temporary file, especially if one has
a hierarchy of files #include 'ing one another.

it seems to work nicely (see examples directory) but i am not too
proficient with the basic syntax to overlook whether there could be
undesired consequences...

it works like this:

./loader /dev/ttyUSB0 getvectors > vectors

../arm-basic-pp -DDEBUG -I. program.bas |cat vectors - quit.bas |
~/CORIDIUM/basic/compiler/bin/ARMbasic-7.20 > program.hex
./loader /dev/ttyUSB0 upload < program.hex
./term.pl /dev/ttyUSB0

please let me know what you think about this approach.

[brucee]

> i modified cpp to treat ' basic line comment the same way as the
> original cpp treats c++ style // line comments and uploaded some
> (very alpha) code into the files section.
>
> please let me know what you think about this approach.
>

If I had infinite time, I would probably have gone this way, and may
integrate it into BASICtools. Replacing all temp file with pipe had
good and bad points, the good is that temp stuff causes headaches with
Vista, but that is being fixed by switching to the TEMP directory of
Windows. The bad is sometimes its hard to figure out what went wrong
with a pre-processed step and its nice to see the intermediate file to
debug on occasion.

As I remember the ' inside a string is the only special case. And
BASICtools does chase down nested #includes already. But
simplification of BASICtools using a modified cpp would be desireable.

[YahooArchive]

I updated the basic-aware modified cpp in the files section.
it should compile now from scratch under linux.
the essential changes are in libcpp/lex.c and the two new files
pp.c and output.c. i didn't try to compile under windows yet.

[YahooArchive]

Would it be possible post a statically linked linux executable of the
ARMbasic compiler? Some older linux distributions are using pre
glibc-2.4 and do not run the dynamically linked ARMbasic-7.20 provided
in the files section.

[YahooArchive]

> Would it be possible post a statically linked linux executable of the
> ARMbasic compiler? Some older linux distributions are using pre
> glibc-2.4 and do not run the dynamically linked ARMbasic-7.20 provided
> in the files section.
>

If you tell us how to do that, we probably could***.

Would that work for newer Linux's or would both be needed?

***like I say, we are not Linux people.

[YahooArchive]

--- In ARMexpress@yahoogroups.com, "basicnode" <bruce@...> wrote:
>
> > Would it be possible post a statically linked linux executable of the
> > ARMbasic compiler? Some older linux distributions are using pre
> > glibc-2.4 and do not run the dynamically linked ARMbasic-7.20 provided
> > in the files section.
> >
>
> If you tell us how to do that, we probably could***.
>
> Would that work for newer Linux's or would both be needed?
>
> ***like I say, we are not Linux people.
>

just add the flag -static in the last step linking all object modules.
something like this:

gcc -O2 -Wall -o ARMbasic.o ARMbasic.c
gcc -static -o ARMbasic ARMbasic.o other_modules.o [-l libraries]

in the simplest case (only one module)
it's convenient to do all at once:

gcc -static -O2 -Wall -o ARMbasic ARMbasic.c

A static executable should be pretty portable as it does not require
any libraries from the system at runtime and only depends on the
kernel interface. Since your compiler probably only needs very basic
things in libc like malloc and stdio it should run pretty much
everywhere. However, statically linked programs are unnecessarily big,
waste RAM, and libs cannot easily be overloaded, that's why usually
dynamically linked executables are distributed.

Since it is so easy to do, you should probably provide both variants:
for the static linkage add the -static switch to gcc, for the regular,
dynamic linkage just omit it.

Note to self, I was looking for this link in the Yahoo Forum, but could never find it, I will comply with the request

[YahooArchive]

Like we didn't have enough to do...

Anyway a couple years back an effort was started to port the tools to a Mac
mini. It got as far as trying to connect up to a USB serial connection just to
find that at the time (and maybe still) Tcl on the Mac doesn't support USB
serial devices.

It pretty much sat there until this weekend. As I was retiring an older PC, I
installed Ubuntu on it. And what the heck let's try again. Anyway TclTerm
pretty much came up right away. BASICtools with a little more difficulty, but
its mostly functional now. If it weren't for one of those "change 2 bytes in a
string in the compiler that shouldn't change anything meaningful" that broke the
compiler for a few days, it would be ready to go.

I'm basically a Linux casual user, no desire to switch, so I could use some
pointers and direction from those who would benefit from it.

Ubuntu will be the main platform for now, with andLinux running on another PC
which is more convenient for some things (too bad it doesn't seem to support USB
serial devices either).

Here's where I'd propose we put things

/usr/bin
BASICtools.tcl
bpp
ARMbasic
TclTerm.tcl

/etc/coridium
store config files here -- could continue to call them .ini or .tcl since
that's what they are

/tmp/coridium
build files here (like bpp output)

where to put doc's (may leave most on the web, there isn't much use for man
files here)

This will be the same GUI running on the PC.

Any feedback on how to do the install (rpm package apt ...) ??

While a command line interface could be done, it would be a major rewrite, not
that it might not be due. And that may be what's needed to do a Mac as its
still not clear whether USB serial interface is available in Tcl.

[YahooArchive]

--- In ARMexpress@yahoogroups.com, "basicnode" wrote:
>
> I'm basically a Linux casual user, no desire to switch, so I could use some
pointers and direction from those who would benefit from it.
>

There's a discussion currently running in the LPC2000 Yahoo Group that might
give you a few insights:

"LPC development and Linux environment"

http://tech.groups.yahoo.com/group/lpc2 ... sage/49381

Regards,
Chris Burrows

CFB Software
Astrobe: LPC2000 Oberon-07 Development System
http://www.astrobe.com