Witam.
Jako, że pracuję nad własnym kompilatorem do C zwracam się z pytaniem
Użytkownik wpisuje
printf("%d","<");
fprintf(plik,"%d","<");
Co kompilator powinien wyświetlić, a co zapisać do pliku?
Mam na razie coś takiego.
Tak, żeby to było użyteczne.
Witom,
printf("%d","<");
Podajesz wskaźnik, czyli pod %d wyświetli się adres gdzie znajduje się string w dziesiętnym systemie jako tekst.
Jak podasz '<' to wtedy będzie ascii znak < zamieniony na dziesiętny jako string.
W takiej sytuacji, kompilator zwykle daje ostrzeżenie, że %d służy do wyświetlania signed int, a "<" ma typ cobst char *., Natomiast do pliku byłby zapisany adres w pamięci tego "<", dziesiętnie (znakami ASCII). Więc, jeśli będzie to 0xff01234 -> dziesiętnie 267391540 -> hexdump: 32 36 37 33 39 31 35 34 30. Jeśli adres nie mieści się w 32 bitach, starsza część adresu zostanie ucięta, np. 0xffffff012345 -> dziesiętnie 4278264645 -> hexdump 34 32 37 38 32 36 34 36 34 35. To ucinanie to już jednak kwestia architektury (przykład dla x86_64).
AFAIK co tylko zechcesz — nie jestem specjalistą od C, ale z tego co wiem, to jest undefined behaviour.
Jeśli chcesz napisać własny kompilator to dosłownie wszystko czego potrzebujesz jest opisane w standardzie https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf
Wystarczy że dokładnie zaimplementujesz tę książkę a na pozostałe undefined behaviors możesz reagować w dowolny sposób albo po prostu skopiuj zachowanie z istniejących kompilatorów
@obscurity:
Mam na myśli to - niewidzialne kody ascii ctrl-c , ctrl-v, exe będzie można swobodnie kopiować.
Jeszcze nie wiem do czego to się przyda ale będzie w standardzie.
Albo to - 
Odkryłeś nieprintowalne znaki :P
Ale to nie koniec, jak odwrócisz świat to istnieje równoległy gdzie można za pomocą pisanego tekstu wygenerować opcode, który będzie pełnoprawnym programem wyłącznie napisany znakami printowalnymi, zwykłym tekstem w dodatku nie będzie wymagać żadnej kompilacji po prostu zapiszesz w pliku jako tekst i uruchamiasz.
Nie wygląda dziwnie?
Panie, przebacz im, bo nie wiedzą co mówią
johnny_Be_good napisał(a):
Witam.
Jako, że pracuję nad własnym kompilatorem do C zwracam się z pytaniem
Zacznij od wiedzy, co to jest kompilator, czym nie jest, i czym się różni od reszty zapieprzajacych krasnoludków.
Po ostatnim jak wyszło, że nie czytamy manuala to za wcześnie się za to zabrałeś. Jak tam Standard C, mamy już w ręku drafta?
Najprostsza odpowiedź: odpal sobie clanga czy gcc i zobacz co mówi. ( Pod windowsem zadziała na cygwinie ).
Twój Kompilator powinien dokładnie to mówić co tam będzie napisane.
@johnny_Be_good W przykładach widzę inicjalizację tablic poprzez określenie wartości elementów w nawiasach kwadratowych (a nie klamrowych) i inne dziwne rzeczy. To na pewno ma być C, czy jakiś twój język C-podobny? Odpowiedź na twoje pytanie dostałeś już w pierwszej odpowiedzi w wątku, ale jeżeli masz takie problemy, to przy tworzeniu kompilatora czekają Cię trudniejsze rzeczy, np. rzutowanie typów. Widzę, że masz już zaimplementowane wskaźniki (jako uchwyty plików), więc czy Twój kompilator poprawnie uruchomi poniższy kod z arytmetyką wskaźników?
#include <stdio.h>
int main () {
FILE *fp;
int i;
fp = fopen ("test.txt", "w");
if (fp == NULL)
return 1;
i = 1;
while (i <= 4)
fp += i++;
fp -= 10;
fprintf (fp, "Test");
fclose (fp);
return 0;
}
@johnny_Be_good: ten twój kompilator jest gdzieś dostępny do przetestowania?
Patrzcie tworzę nowy typ zapisu roboczo to nazwałem TWriteIndexer - zapisuje bajty w 7 bitowej notacji ,jeśli liczba % 8 >0 to zapisuje msb na 1 i leci z następnym. xD (coś jak utf-8 tylko version unlimited)
Czyli fprintf(plik,"%t",75757575757); a zapisze najpierw "1,0,1,1,0,0,1,0,0,1,1,1,1,0,1,1,0,0,0,0,0,0,0,1,1,1,0,0,0,1,0,1,1,0,1,1,0,0,0,0,0,0" - ostatni bit to 0 - czyli kończy wczytywanie bajtów zindexowanych, usuwa każdy co 8, potem pętlą robi Math.pow(2,i); albo bitwisem , i wczytuje daną liczbę bajtów
jak będzie fprintf(plik,"%t",1); to zapisze 1,0,0,0,0,0,0 , a potem jeden bajcik.
No i %t powinno to chyba zamienić na liczbę a %T na tablicę wartości liczbowych kodu ascii się domyślam
,więc fscanf(plik,"%t",zmienna); wczytuje najpierw bity dokąd msb == 1 a potem konwertuje na rozmiar bajtów do wczytania.
Na pewno będzie przydatne do zapisywania np. liczby w postaci kodu ascii.
Planuję to zrobić jako prefix do zapisywanych danych (bo używanie linijek do zapisu profesjonalne mi się nie wydaje)
A myślę jeszcze nad jednym typem danych gdzie liczba danych zapisywana by była na 2?3 bitach a reszta dopełniana wartością "następnika" (czyli wartości zapisywanej). Do mniejszch rozmiarów.
A tutaj liczby w bajtach jakie są zapisywane
No dobra zapisy chyba się zgadzają
Tak jakby fscanf działało dla %d
Z dynamicznym ustawianiem rozmiaru.
Adresowanie małych liczb 2(30) wygląda teraz tak - dynamicznie alokowane.
Proszę Państwa tak wygląda fachowa robota.
Małe liczby zajmują tyle co zwykły typ znakowy, za to dwu bajtowa to już 16 000
String to już ciąg rozmiaru dynamiczny.
I zapis liczby.
I tak to powinno wyglądać od początku.
A za pomocą Object.getOwnPropertyNames() to będę serializował całe obiekty w biegu.
Tak jak pisałem fscanf z małym upgradem - tworzy string wyjściowy bez potrzeby określania danych formatowania.
10 bitów straty, i chyba przy każdym większym rozmiarze stringa maksymalnie będzie 7 na jeden łańcuch znaków, 2 na liczbę
