long ausgabe mit printf

Hmm, im AVR-GCC geht das (und es geht genau so), und in dessen Forum
befindest du dich hier...

Was sagt denn die Dokumentation deines Compilers?

%ld ist schon voll o.k. so für konforme C-Compiler.

In der Codesammlung hat jemand nur für Codevision %ald gepostet, keine 
Ahnung, was das bedeutet.


Peter

Ich arbeite mit dem arm-elf-gcc, und hab gerade das gleiche Problem.
Ich hab einen 64-bit integer, den ich per printf mit %ld an das Terminal 
senden möchte. Leider kommen nur kryptische Zeichen an.

%ld erwartet aber auch einen long int, aber int64_t ist mit long long 
definiert. gibts dafür eine einfache Lösung?

Wenn deine Bibliothek es kann: %lld.

Anscheinend kann sies nicht.

Hier das Programm:

1

#include <board.h>

2

#include <pio/pio.h>

3

#include <dbgu/dbgu.h>

4

5

#include <stdio.h>

6

#include <stdint.h>

7

8

/// Pio pins to configure.

9

static const Pin pins[] = {PINS_DBGU};

10

11

int main(void)

12

{

13

    int32_t l1,l2;

14

    int64_t l3;

15

16

17

    PIO_Configure(pins, PIO_LISTSIZE(pins));

18

    DBGU_Configure(DBGU_STANDARD, 115200, BOARD_MCK);

19

    printf("\n-- ATMEL ARM7 Dummy Project 1.4 --\n\n");

20

21

    l1=2000000000; // 2 Mrd

22

    l2=0x77359400; // 2 Mrd

23

    l3=(int64_t)l1*l2;

24

    printf("2Mrd * 2Mrd = %lld\n",l3);

25

26

    return 0;

27

}

der GDB zeicht in Eclipse für l3 das richtige Ergebnis an.
Als Ausgabe erhelte ich im GtkTerm

1

-- ATMEL ARM7 Dummy Project 1.4 --

2

2Mrd * 2Mrd = ®ÊÀ؇˜&ÈúːSÒ°KÜeý^Á

3

ºŸ2äů‘WªD—1U/êîvkÕáꦂ @€6$

> hängt aber nicht direkt von den Sourcen ab, eher vom verwendeten
> Windows-Compiler, um die GCC sourcen zu erstellen.

Das ist aus zweierlei Gründen zu bezweifeln, einerseits wird kein 
Compiler verwendet, um "die GCC sourcen zu erstellen", andererseits wird 
gcc auch unter Windows mit sich selbst übersetzt.

chris wrote:
> Das ist aber leider so. Windows Ports werden meistens mit MING
> compiliert,
> eine GCC Portierung auf Windows, welche die Newlib benutzt.

Der Haken dabei ist wohl, dass newlib halt kein richtiges Projekt
ist, sondern lieblos und wenig gepflegt von irgendwoher zusammen
gezogener Sourcecode für eine (einigermaßen) Standardbibliothek,
die nicht den Limitierungen der (L)GPL unterworfen ist.  So findet
sich da offenbar eine uralte (lange vor ISO C99 geschaffene)
Variante der BSD-libc wieder, die damals L als modifier für long
long int benutzt hat.  Wenn die Leute mal ihre Quellen von einem
einigermaßen aktuellen FreeBSD aktualisieren würden, dann wäre das
Dilemma behoben.

Für Karl heißt das aber wohl, dass er sich auch mit %Ld behelfen
kann.

Alos %Ld funktioniert genausowenig wie %lld... Ich brauch die Funktion 
grad nicht wirklich, aber trotzdem schade.

lg

Dann kannst du dir nur mit dem Selbstportieren einer der diversen
BSD-Bibliotheken behelfen, wenn du's mal brauchst.

hört sich nach viel arbeit an...

Karl Zeilhofer wrote:
> hört sich nach viel arbeit an...

Ist an einem Abend gemacht.  Man sollte sich unterschiedliche
Versionen vornehmen, aktuelle Versionen sind auf Grund der später
eingebauten C99-Features u. U. etwas komplexer geworden.  Ggf. mit
einem ursprünglichen 4.4BSD beginnen, da bin ich mir nur nicht ganz
sicher, ob's da schon long long gab.

Für solche Debug-Zwecke hatte ich mir deshalb mal eine eigene 
eingedampfte Version von printf gestrickt. Schon auf Platzgründen wollte 
ich beim ARM auf die newlib verzichten-

Sollte ziemlich universell einsetzbar sein, sofern alloca() existiert 
und "unsigned long long" der maximal verfügbare Integer-Typ ist.

Ist Originalfassung, die Includes müssen angepasst werden, config,h kann 
man streichen.