ես պարբերաբար փորձել եմ գրել makefile որը
ու մէկ ա կան խնդիրներ ու ամէնը վատ ա։
դրա լուծումն էլ կայ՝ vipack֊ը։
ոչ makefile֊ները ոչ git֊ը չեն կարողանում նորմալ կառավարել կախուածութիւնները։ ու էդ օկ ա որովհետեւ էդ իրենց գործը չի։
ինձ էսօր պէտք ա makefile միայն երկու անգամ՝ որ հաւաքեմ voc֊ը ու որ voc֊ով հաւաքեմ vipack֊ը։
դրանից յետոյ makefile֊ներ այլեւս պէտք չեն։ git ենթամոդուլներ կամ ենթածառեր պէտք չեն ու միայն խանգարում են։
vipack ու միայն vipack֊ը այլեւս բաւական ա պրոյեկտներ շինելու համար։
vipack֊ը էն գործիքն ա որ պէտք ա, ու պէտք ա իրականում ոչ միայն ինձ ու ոչ միայն օբերոնի աշխարհում։
vipack֊ով կարելի ա եւ գուցէ պէտք ա շինել ամէն ինչ։
ես պարզապէս հասկանում եմ ինչքան հրաշալի գործիք ենք ստեղծել։ ու սկսուել ա ամէնը որպէս @shekspir55@xn–69a.xn–99axc.xn–y9a3aq ֊ի թէզ։
ու տէնց։
#vipack #voc #օբերոն
this is a very good blog post՝ back to basics about strings in C and Pascal. i suggest you to read it, and now i’ll tell you something else:
in Oberon, Wirth decided to give up on Pascal strings, and use zero terminated strings.
however, there is no need to run by the whole array to find out the length of the string. we don’t even need to have a separate field that holds the length՝ compiler knows the length of the static string.
thus it can do compile time tests. for example we have the following Oberon source՝
MODULE tst;
IMPORT Out;
VAR i: SHORTINT;
str: ARRAY 1024 OF CHAR;
BEGIN
FOR i := 0 TO LEN(str) DO
Out.Int(i, 0); Out.Ln
END;
END tst.
lets try to compile it՝
[2020-09-02 16:00:20] $ voc -m tst.Mod
tst.Mod Compiling tst.
9: FOR i := 0 TO LEN(str) DO
^
pos 102 err 113 incompatible assignment
Module compilation failed.
[2020-09-02 16:00:21] $
voc compiles Oberon source to C, which is very good to illustrate what happens. if we have՝
str: ARRAY 16 OF CHAR;
then the output C code will be՝
static CHAR tst_str[16];
nothing more։ no field for the length.
still, this՝
FOR i := 0 TO LEN(str) DO
will translate to՝
tst_i = 0;
while (tst_i <= 16) {
as i said we know the length at compile time. doesn’t matter if you generate C or assembly, you already know the number, you can put the number to the output assembly code as well.
when we write a function which receives strings, we should not knowt the length of the received string, we just use ARRAY OF CHAR as an argument՝
MODULE tst2;
PROCEDURE addStrs(VAR a, b: ARRAY OF CHAR);
BEGIN
(* do smth useful here *)
END addStrs;
PROCEDURE test*;
VAR
s0: ARRAY 32 OF CHAR;
s1: ARRAY 64 OF CHAR;
BEGIN
addStrs(s0, s1);
END test;
END tst2.
therefore C code will be՝
static void tst2_addStrs (CHAR *a, ADDRESS a__len, CHAR *b, ADDRESS b__len)
{
/* here we think we can do smth useful */
}
void tst2_test (void)
{
CHAR s0[32];
CHAR s1[64];
tst2_addStrs((void*)s0, 32, (void*)s1, 64);
}
as we see՝ the function also gets the length of strings. and if we do LEN(a) we get the length without any calculations.
now let’s see how dynamic strings work՝
MODULE tst3;
PROCEDURE addStrs(VAR a, b: ARRAY OF CHAR);
BEGIN
(* do smth useful here *)
END addStrs;
PROCEDURE test*(i: INTEGER);
VAR
s: ARRAY 32 OF CHAR;
ps: POINTER TO ARRAY OF CHAR;
BEGIN
NEW(ps, i);
addStrs(s, ps^);
END test;
END tst3.
now we hase a static string՝ s and we allocate a dynamic string with its pointer ps.
lets assume we don’t know the size of ps^ string (^ means dereference) and we will receive the length of the allocated string as a function argument. it is not known at compile time.
first function remains unchanged, second function gets translated like this՝
static void tst3_addStrs (CHAR *a, ADDRESS a__len, CHAR *b, ADDRESS b__len)
{
/* do smth useful here */
}
void tst3_test (INT16 i)
{
CHAR s[32];
struct {
ADDRESS len[1];
CHAR data[1];
} *ps = NIL;
ps = __NEWARR(NIL, 1, 1, 1, 1, ((ADDRESS)(i)));
tst3_addStrs((void*)s, 32, (void*)ps->data, ps->len[0]);
}
the _NEWARR is a bit more complicated function, which is a part of the runtime.
but we can understand what it does՝ it allocates a space in the heap, and the pointer ps we get now points to the struct, which has a data field and len field.
this is a runtime information, and in this case we have to keep a separate field for the length of the string.
that’s it.
#oberon #c #pascal #wirth #programming #programming-languages #programming_languages #design #implementation #vishap #voc #compiler #compilation #strings #string #heap #stack #storage #storage-management #storage_management #length
now it’s better (than the commented version)
@{Antranig Vartanian ; antranigv@spyurk.am} 17.05.2017, 22:29:36
solving https://www.reddit.com/r/dailyprogrammer/comments/68oda5/20170501_challenge_313_easy_subset_sum/
#DailyProgrammer #Oberon #Oberon-2 #voc ##
#programming #screenshot
@{Antranig Vartanian ; antranigv@spyurk.am} 17.05.2017, 22:29:36
solving https://www.reddit.com/r/dailyprogrammer/comments/68oda5/20170501_challenge_313_easy_subset_sum/
#DailyProgrammer #Oberon #Oberon-2 #voc ##
apparently, my forking server example (:
#oberon #hn #screenshot #voc #vishap #irc #example #programming
something about new warning message։
#oberon #voc #programming #screenshot
#journally #screenshot #voc
added an example from Reiser’s book. IFS, Iterated Function System.
@{
Փրչրթան✱ Թանաքեան ; norayr@spyurk.am} 28.08.2014, 14:49:37
աւելացրի Ռայզերի գրքից մի օրինակ։
#վօկ #վիշապ #ծրագրաւորում #նկար #գրաֆիկա #մաթեմ
#voc #vishap #oberon #programming #graphics #math
added more beautiful error/warning messages in voc
@{ Փրչրթան✱ Թանաքեան ; norayr@spyurk.am} Չրք 07 Մայ 2014 08:21:34 AMT
աւելացրի սիրունիկ սխալների զեկոյց։
#վօկ #վիշապ֊օբերոն #կոմպիլյատոր #էկրանահան #կոնսոլ #նոչ #ուտենց
#voc #vishap-oberon #xterm #console #noch #screenshot #wmaker
պատահաբար հանդիպեցի՝ http://listarc.com/showthread.php?5356219-FPGA+toolchain+again. (:
#oberon #voc #vishap #feedback #compiler
վիշապ օբերոն կոմպիլյատորի մակոսի պորտը նոր աւարտեցի։ ։Ճ
i’ve just finished macosx port of vishap oberon compiler
#oberon #voc #vishap #compiler #macosx #programming
ասք վիշապին մակում բնակեցնելու մասին՝ http://norayr.arnet.am/weblog/2014/03/20/ասք-վիշապին-մակում-բնակեցնելու-մասին/
#voc #oberon #clang #vishap #վիշապ #հետազօտութիւն #ասք #ծրագրաւորում #ուտենց
https://github.com/norayr/voc/commit/a3214b81549d7c1d4654c62af52514261ed08ed0
different modules can be now compiled into one elf at once (no separate linking command needed). for example, if M0 imports M1 then
voc -l M1.Mod -s M0.Mod -M
where -l is a global option (show line numbers, I don’t use it, I need only position, and do :goto in vim to get it)
-s means generate symbol file, we need it to compile M0, and check types throughout module boundaries
-M means generate main module and link it statically to libVishapOberon.
#voc #vishap-oberon #oberon #oberon-2 #compiler #linking #programming
I have published Vishap Oberon compiler
#vishap #voc #oberon #oberon-2 #compiler #ofront #pascal #modula-2 #fork #github #compilers #վիշապ #օբերոն #կոմպիլյատոր #պասկալ #մոդուլա֊2 #ծրագրավորում
