JAL compileertijd tot 19u

Hallo,

Ik gebruik al een tijdje JAL (= Just Another Language, http://justanotherlanguage.org/) om programma's voor PIC's te maken. Ik was hier altijd zeer tevreden over (zeer duidelijk, de libraries kan je zelf volledig aanpassen en bijmaken).

Nu mijn programma's langer en complexer geworden zijn (PIC18F4550, USB, 800 regels), is de compileertijd steeds toegenomen, op dit moment is dit 17 uur (op een 3,6GHz processor computer).
Dit vind ik nu wel vervelend dat het zo lang duurt voordat je je programma kan proberen en dat je nog eens zo lang moet wachten ook als je maar een heel klein foutje gecorrigeerd hebt.

Bestaat hier een oplossing voor?
Welke andere soortgelijke gratis programma's zouden jullie mij hiervoor aanraden? Duurt het compileren hierbij ook zo lang?

Met dank bij voorbaat,
Tom

Frederick E. Terman

Honourable Member

Uit de JAL FAQ:

The minimum PC I would recommend for using JAL is a 486-33 with 8Mb.

Dat is 109 x zo langzaam als jouw machine, nog afgezien van het geheugen. Die pc zou dus bijna drie maanden over het compileren van jouw 800 regels gedaan hebben. Dat is tien regels per dag.

Als dat echt zo was, zouden daar vast weleens klachten over geweest zijn. Ik denk daarom dat er iets anders bij je installatie aan de hand is.
Kun je eens een 'verse' installatie op een andere pc (bijvoorbeeld een afgedankte laptop) proberen?

Keramisch, kalibratie, parasitair: woordenlijst.org
benleentje

Golden Member

Wat FET heirboven zegt lijkt me het meest aannamelijk er moet ergens iets in de pc fout gaan waardoor de boel enorm vertraagd.

Er is toch ook ergen wel een JAL forum, je kan het beter daar dan vragen die zullen wel weten hoelang 800 regels normaal zou moeten duren.

Mensen zijn soms net als een gelijkrichter, ze willen graag hun gelijk hebben.
Arco

Special Member

Veel programma's hebben problemen met 'verdwenen' drives, die wel in hun searchpath zitten.
Bij iedere actie wordt dan getracht die drive aan te spreken, wat niet lukt en resulteert in lange wachttijden.
(kan bijv. een SD card of USB stick/drive zijn die verwijderd is)

Hoewel 17 uur in geen enkel geval acceptabel en/of verklaarbaar is...

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com

Ik denk voor het compileren van heel Windows 10 die 19 uur nog enorm lang is!

"We cannot solve our problems with the same thinking we used when we created them" - Albert Einstein
Arco

Special Member

Als die tijd normaal was, hadden ze het wel JSL genoemd...   (Just a Slow Language :))

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
buckfast_beekeeper

Golden Member

De genoemde tijd is veel te lang voor de gegeven processor. Ik denk dat niemand die tijd zou accepteren. 800 regels is ook nog niet mega. Zelfs als JAL maar 1 core van je CPU gebruikt is dit veel te lang.

Buiten de reeds aangehaalde mogelijke fouten kan ik er maar 1 meer bedenken. Te weinig geheugen. Maar zelfs dan is de gegeven tijd nog heel lang.

Als ik C code voor een AVR compileer duurt dit enkele seconden.

Van Lambiek wordt goede geuze gemaakt.

Sommige oudere compilers lezen de files byte voor byte wat tegenwoordig ervoor zorgt dat telkens een groot blok wordt gelezen. Maak eens een ramdisk en run daarop?

Ik heb het op 3 verschillende computers geprobeerd (windows xp, windows 7, windows 10) en overal heb ik dit probleem.

Ik heb het geïnstalleerd via https://www.elektor.nl/support-pic-microcontrollers van de boeken van Bert Van Dam.
(Wanneer ik de originele jal installeer en enkel de libraries verander in de hiertoe voorziene map, werkt het niet.)

@Hoeben: bullshit, de read/write buffers zorgen er wel voor dat het prima mogelijk is om byte voor byte te lezen met acceptabele snelheid (megabytes per seconde).

Het kan ook uitmaken waar je je files opslaat; bij mij wil LTspice nog wel eens minutenlang hangen op een output file die op een of andere manier nog gelocked is. Als je de output file verwijderd is het probleem over.

Je kunt natuurlijk ook gewoon, net als de rest van de wereld, in C gaan programmeren, dan kun je ook nog eens overstappen op een andere controller als dat handig uitkomt. Ik heb code geschreven voor meerdere families van TI, ST, AVR, Microchip, Freescale, en dan vergeet ik er vast nog wel wat; vrijwel altijd in C, en dat maakt het heel gemakkelijk om over te stappen en code mee te nemen.

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken
Arco

Special Member

Je kunt natuurlijk ook gewoon, net als de rest van de wereld, in C gaan programmeren

Zelfkastijding is niet strikt noodzakelijk; basic kan ook... :)

en dat maakt het heel gemakkelijk om over te stappen en code mee te nemen.

Da's wel heel kort door de bocht. Meestal zijn support libraries compleet verschillend bij andere MCU's/compilers... Blijft dan toch wel wat werk...

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com

Wanneer ik de outputfiles verwijder voor ik start, duurt het ook zo lang.

In bijlage een printscreen van taakbeheer.

Na een nieuwe uitbreiding van mijn programma is hij nu al 24u bezig...

EricP

mét CE

Zelfkastijding is niet strikt noodzakelijk

Die keuze is toch al gemaakt toen TS besloot met pic-dingen aan de gang te gaan??

Je kunt natuurlijk ook gewoon, net als de rest van de wereld, in C gaan programmeren

Precies. Het zou een reden kunnen hebben dat die taal heel veel gebruikt wordt - en de reden heet hier niet 'marketing'.

Maar goed... Blijkbaar struikelt dat JAL-ding ergens over. Het feit dat-ie 'slechts' 28% CPU gebruikt, lijkt erop te duiden dat die tool ergens op staat te wachten - anders had je 50% (voor een dual core) of (tegen de) 100% (voor een single core) verwacht.

Vroeger, toen mijn zelfkastijding nog 'windows' heette, heb ik ook wel eens zoiets aan de hand gehad. Ergens een update die wat settings mbt. caching stuk gemaakt had. Vanalles was niet meer vooruit te branden. Blijkbaar ook een volgorde-afhankelijkheid. Een her-installatie (het blijft windows he...) loste het probleem op.

Ik zou het eens in die hoek zoeken. jal wordt ergens niet blij van. Je zou eens kunnen kijken of je de config kunt wegmieteren en opnieuw opzetten en als dat niet kan / helpt het eens op een andere computer proberen.

Compilatie tijden voor zowel AVRs als 8051s onder C ziten altijd in de 'seconden' hoek. Goed, voor een 8051 met 60k aan object code wel eens een tiental. Maar de minuut haalde het nooit. Zelfs als jal erg onhandig compileert en een factor 10 onhandiger is, dan druk je het nog steeds uit in minuten en niet in uren.

je zou met process explorer eens kunnen kijken welke handles het apparaat open heeft.

EricP heeft gelijk, het is waarschijnlijk (disk) IO die de bottleneck is, niet de CPU.

https://technet.microsoft.com/en-us/sysinternals/processexplorer.aspx

GMT+1

Op 20 mei 2017 09:15:10 schreef Progger:
je zou met process explorer eens kunnen kijken welke handles het apparaat open heeft.

EricP heeft gelijk, het is waarschijnlijk (disk) IO die de bottleneck is, niet de CPU.

https://technet.microsoft.com/en-us/sysinternals/processexplorer.aspx

Ik heb dat ook vaker gezien met oude compilers. Cachen in RAM of een ramdisk doen dan wonderen.

Vaak kun je opgeven waar de scratch area of hoe ze tijdelijke opslag ook noemen mag liggen. Leg die in een ramdisk.

Zo oud is dat JAL nou ook weer niet hoor. Komt niet uit de jaren 80 of zo.

TS, ik zou toch proberen om de compiler schoon te installeren, de laatste versie. Dan libraries ook op de juiste manier erbij installeren. Dat is hou het zou moeten werken. Als het niet werkt, los dat dan op. Dat lijkt mij een beter pad dan een oude setup debuggen (wat blijkbaar structureel niet gaat, op meerdere machines).

"We cannot solve our problems with the same thinking we used when we created them" - Albert Einstein

In 1986 weet ik dat turbopascal zo'n 20000 regels per seconde compileerde. Die orde van grootte. Maar dat was omdat ze daar trots op waren.

Ik heb een (embedded) project van mij gecompileerd. 1600 regels in mijn project directory, maar ruim 10x meer in library/os code. Het kost 4.5 seconde om de 18275 regels te compileren (en linken). Het overgrote deel daarvan (2/3e) is de tijd die het kost om de zooi de eerste keer van disk te lezen. Een tweede compile (met alle objecten weggegooid) kost maar 1.5 seconde.

Dat komt op 12000 regels per seconde mits de sources en compiler al in RAM zitten.

Dus in 30 jaar zijn computers ongeveer 30000 maal sneller geworden (Moore), maar kost compileren ongeveer 40000 maal meer computer-moeite. Tja, zal wel.

Maar 800 regels compileren in meer dan 10 seconden, dan is er iets mis.

[edit: Turbo pascal rekende de header regels die steeds opnieuw gecompileerd werden mee en pre-compileerde die om snelle compile-tijden te halen. Als ik de headers meereken, haalt mijn compiler nu 182k regels per 1.5 sec, 120k regels/sec. )

[Bericht gewijzigd door rew op zaterdag 20 mei 2017 10:12:17 (13%)

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

Ik ben gewoon van te programmeren met Visual basic, dus als ik zou overschakelen van taal, denk ik dat ik liefst basic zou gebruiken. Is dit Proton PIC Basic of zijn hier nog andere programma's van? Dit is niet gratis precies?

Wat ik heel interessant vindt aan JAL is dat je met de libraries de weg van de commando's volledig kan "volgen" van de JAL taal naar de assembler taal. Hierdoor kan je op alle stappen alles volledig aanpassen zoals je wil en kan je ook zelf commando's bijmaken. Is dit ook het geval in basic?

[Bericht gewijzigd door elektronica op zaterdag 20 mei 2017 11:50:27 (40%)

Wat ook soms vertaging geeft is de virusscanner.
Ik had dit met het compileren van arduino sketches.
Nadat ik de virusscanner had verteld dat die de projectfolder met rust moest laten ging het vele malen sneller.

Arco

Special Member

Je kunt Mikrobasic eens downloaden en proberen.(tot 4k code limit is 'ie gratis). Op Libstock is ook genoeg aan libraries te vinden daarvoor...

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com

In mijn huidige programma's gebruik ik RS232 emulatie van de usb poort, zodat ik in windows een virtuele com poort zie staan. Op het eerste zicht vind ik hiervoor geen library in microbasic.

Hoe kan je hier bytes verzenden en ontvangen via usb (naar visual basic op de computer)?

Arco

Special Member

Je zult dan wel een USB-UART converterchip gebruiken, daar zit normaal een driver bij. (heeft niets met compiler te maken)
USB direct gebruiken is wel e.e.a. over te vinden: https://libstock.mikroe.com/project_categories/view/22/usb

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com

Neen, de PIC hangt rechtstreeks aan de pc via de USB poort van de PIC, en op de computer zie ik dan COM9, wat de pic is.

Bestaat er voor microbasic ook zo'n library?

Arco

Special Member

Ik begrijp niet hoe je dat precies bedoelt. Als je al een USB <-> USB connectie hebt, waarom dan nog een COM poort emuleren?
(voor virtuele com poort via USB gebruik ik normaal iets als een MCP2200 via UART)

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com

Ik deed dat eigenlijk omdat JAL die library heeft en omdat ik in visual basic goed met de com poort kan werken...

Wat ik eigenlijk wil doen is een byte kunnen verzenden van visual basic naar de pic en omgekeerd. Wat zijn de mogelijkheden hiervoor in microbasic? Hoe kan ik dit integreren in visual basic op de pc?