Prev: IEEE was Re: Photodiode readout without transimpedance amplifier
Next: Intel chimes
From: MooseFET on 12 Jan 2010 09:55
On Jan 12, 4:58 am, Jan Panteltje <pNaonStpealm...(a)yahoo.com> wrote:
> On a sunny day (Mon, 11 Jan 2010 18:36:20 -0800 (PST)) it happened MooseFET
> <kensm...(a)rahul.net> wrote in
[... 8051 and C compilers ...]
> The 8051 assembler was very expensive, I had it on the job, 2500$ or so?
> So, I could not take that home, so I wrote my own in C,
> on my clone CP/M system that I also wrote myself in Z80 asm. :-)
> So that preprocessor would indeed be a possible project.

I also have written my own. It started off as just a project to add
a
feature to an existing one but I discovered that the existing one was
a complete "pigs breakfast" internally. It obviously had been written
by patching bugs.

It is actually not that hard to make a 8051 assembler because each
line
is processed independently of the others except for the symbol values.

>
> >(2)
> >Most C for the 8051 really sucks.  This is because the convert
> >each source file to an object file and then link.  This loses
> >some information that could be used to great advantage on the
> >8051 processor.
>
> Tell me something, I am in the middle of it.
> I use sdcc (open source), it has a C compiler and an assembler.
> It can target 8051, Z80, PIC16, and also PIC18, but only some the latter I think.
> What I wanted to do is compile some universal routines
> that take a RAM address as input, and an other RAM address as output, at org <somewhere in RAM>
> that use all vars in RAM, so I can write real C, and start that main() from
> a BASIC call, and including floating point and math libs.
> I am halfway there, but the C looks weird full of stuff like
>  volatile __xdata __at (0x7000) unsigned char ival1;

My idea was to cause the "C compiler" to output a predigested
intermediate version
and not a fully compiled result. The "linker" would be what actually
makes it into
machine language.

I think you don't want a space between the "_at" and the "(". You can
supply an
include file that looks like this:

#define __xdata__at(foo)
#define __code__at(foo)
.... etc ...

If you include this file, the normal C compiler will like the code
because it doesn't
have any weird stuff in it after the preprocessor is done with it.

[...]
>
> Have a look at 'sdcc', it is big.
>  http://sdcc.sourceforge.net/
> It has a *lot* of command line optimising options, just beginning to investigate them all.

I have looked at sdcc several times and then gone back to assembly.
At this point my code
is mostly calls to existing routines. I have a nice 32 bit math
library. RS-232 routines
and the like. One very nice routine I have takes a 32 or 64 bit
number and formats it with
a decimal place etc. The input values are something like:

R0 A work space of 10 bytes
R1 The number to be processed
R2 The nature of the number:
D7 The number is signed
D6 The number is 64 bit
D3..0 The number of digits below the decimal of the
number its self
R3 The format:
D7..D4 The number of digits before the decimal
D3..D0 The number of digits after the decimal
R4 The options:
D7 Put a plus sign on positive values
D6 Remove leading zeros down to "0."
D5 Remove trailing zeros up to ".0"
D4 Remove ".0" if not needed
D3 Right justify result \ Both means
D2 Left justify result / squash out spaces


> I prefer C, as MCS-BASIC sucks anyways with those line numbers..., and is slow.

I used the basic in a product I shipped. I rewrote it later in
assembler. The
Basic version couldn't keep up in a few cases. The customer for the
first ones
didn't care. The later customers really did.

> I was looking last night at the asm sdcc generates, and indeed your example below is an example of that :-)
>
> >2-C
> >Many of them store things MS then LS and end up doing a whole
> >bunch of extra instructions because the 8051 doesn't have a
> >DEC DPTR  With LS-MS you can do this:
>
> >        MOVX    A,@DPTR    ; Add 1234 to FOO
> >        ADD     A,#34H
> >        MOVX    @DPTR,A
> >        INC     DPTR
> >        MOVX    A,@DPTR
> >        ADDC    A,#12H
> >        MOVX    @DPTR,A
>
> I know, this is from the 8052AH BASIC FAQ:
> QUESTION
> I am writing in assembly language and I notice that the 8052AH has no decrement DPTR instruction.
> What is the easiest. shortest or simplest way to decrement the DPTR?
> ANSWER
> The shortest one we know is:
>                             XCH         A, DPL          ; SWAPA<>DPL
>                             JNZ         DECDP           ; DPH = DPH-1 IF DPL = O
>                             DEC         DPH
>               DECDP:        DEC         A               ; DPL = DPL-1
>                             XCH         A, DPL
> This routine affects no flags or registers (except the DPTR) either!

Yes this is very like what I do in the rare cases I need it. On the
silabs
this may be faster:

XRL DPL,#0FFH
XRL DPH,#0FFH
INC DPTR
XRL DPL,#0FFH
XRL DPH,#0FFH

The Silabs machines slow down if a jump takes you to a new 4 byte hunk
of
memory that doesn't happen to be in cache. I currently have some code
running that uses 95% of CPU time so I care about a machine cycle or
two.
The 95% is in interrupt routines. It is great fun to trouble shoot so
I write with great care.

From: Jan Panteltje on 12 Jan 2010 14:09
On a sunny day (Tue, 12 Jan 2010 06:55:56 -0800 (PST)) it happened MooseFET
<kensmith(a)rahul.net> wrote in
<c8cc513e-52c7-4bac-ad89-3673249a4c2b(a)e27g2000yqd.googlegroups.com>:

>this may be faster:
>
> XRL DPL,#0FFH
> XRL DPH,#0FFH
> INC DPTR
> XRL DPL,#0FFH
> XRL DPH,#0FFH
>
>The Silabs machines slow down if a jump takes you to a new 4 byte hunk
>of
>memory that doesn't happen to be in cache. I currently have some code
>running that uses 95% of CPU time so I care about a machine cycle or
>two.
>The 95% is in interrupt routines. It is great fun to trouble shoot so
>I write with great care.

I have been trying some more sdcc calls from MCS-BASIC.
So far the code seems to execute, but somehow then BASIC messes up
baudrate and I cannot see the result.
So obviously some registers are used by sdcc that are also used by MSC-BASIC.
A puzzle.
Will try some more later ...
:-)
Indeed asm rules, at least you know what happens.
So I disassemble the code generated by sdcc for inspection to see what it does.

Also wrote a program to make data statements in MSC-BASIC from Intel format hexfiles,
so I can just upload the code as BASIC lines.
The line number is the is now address!

10 gosub 24574 : REM sdcc code to RAM
20 xby(7000h)=111 : REM value to be worked on by sdcc code
30 call 24576 : REM call sdcc code
40 print xby(7001h) : REM print result
50 end

24574 REM code from file.bas by hxl from file.hex
24572 REM org=24576 last address used=24693
24576 DATA 2
24577 DATA 96
.....
4691 DATA 130
24692 DATA 0
24693 DATA 34
24694 FOR I=24576 TO 24693
24695 READ A : XBY(I)=A : NEXT
24696 RETURN


With one byte per data statement, for short routines this should do.
The 'hxl' program is still being developed, if anyone wants a copy ask me.
 | 
Pages: 1
Prev: IEEE was Re: Photodiode readout without transimpedance amplifier
Next: Intel chimes