AsmBB

Power
Login Register

Error detected
0

0 1 2
#15843 (ツ) KyberMax
Created 30.04.2019, read: 4806 times
johnfound

Зачем мучить бедного гугл переводчика?

Let him suffer for not knowing English.

April 28, the comedy "The Diamond Arm" turned 50 years old.

Vanya, how is your leg? No pain? Can you move your fingers? No, not on the arm, on the leg. Good, you'll be OK.

I looked through the source code of fasm and thought that it might be possible to try to arrange in the past so that the author of the fasm would meet with the great Austalian humanist and show him the source code? Obviously, after this meeting, another shallow grave will appear in the Australian bush, and you will now be the elite programmer on MASM. What do you think?

#15844 (ツ) johnfound
Last edited: 01.05.2019 by johnfound, read: 4804 times
KyberMax
johnfound

Зачем мучить бедного гугл переводчика?

Let him suffer for not knowing English.

April 28, the comedy "The Diamond Arm" turned 50 years old.

Vanya, how is your leg? No pain? Can you move your fingers? No, not on the arm, on the leg. Good, you'll be OK.

I looked through the source code of fasm and thought that it might be possible to try to arrange in the past so that the author of the fasm would meet with the great Austalian humanist and show him the source code? Obviously, after this meeting, another shallow grave will appear in the Australian bush, and you will now be the elite programmer on MASM. What do you think?

On NASM, not MASM. Also I think:

My picture

Attached files:
FileSizeUploadedDownloadsMD5 hash
quote.jpg20624 bytes01.05.2019754a9fea3ce565f6a819f80c4d2d107324a
#15845 (ツ) KyberMax
Last edited: 02.05.2019 by KyberMax, read: 4794 times
johnfound

On NASM, not MASM.

OK, as you wish.

johnfound

Also I think:

https://board.asm32.info/!attached/38

What code? Everything is linked with libraries.

https://i.pinimg.com/originals/94/b9/84/94b9844b7f04e53f3f065fdca91b36ad.jpg

#15846 (ツ) KyberMax
Last edited: 08.05.2019 by KyberMax, read: 4786 times

I remembered that I have several small programs written without links to libraries. Here is one of them, written back in 2016. It shows the obvious superiority of using MASM over other Assemblers when creating programs with Unicode support. When non-MASM programmers use macros, strings from resources or stupidly manually translate Unicode letters into codes, modest MASM programmers simply write the source directly in Unicode.

Something like that, for example (at the same time, we will check how this forum supports Unicode):

;
.386
.MODEL FLAT, STDCALL
OPTION CASEMAP: NONE
;
IncLib MACRO fn
INCLUDE \Masm32\INCLUDE\fn.inc
INCLUDELIB \Masm32\LIB\fn.lib
ENDM
;
MovE MACRO dst, med, src
	MOV	med, src
	MOV	dst, med
ENDM
;
INCLUDE \Masm32\INCLUDE\Windows.inc
;
IncLib User32
IncLib Kernel32
;
INCLUDE HelloUcW.inc
;
WmMouseOverBtn	EQU	7FFFh
MovTimerId	EQU	1
MovTimerPer	EQU	15
BtnStepNum	EQU	10

;
WM	TYPEDEF	Dword
ID	TYPEDEF	Dword
ND	TYPEDEF	Dword
PSZ	TYPEDEF	Ptr CHAR
PWSZ	TYPEDEF	Ptr WCHAR
PCODE	TYPEDEF	Ptr Proc
;
BTN_MOV STRUCT
Xcur	ND	?
Xstep	ND	?
Xmin	ND	?
Xmax	ND	?
Y	ND	?
Width_	ND	?
Height	ND	?
BTN_MOV ENDS
;
prDlgMain	PROTO	hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM
prBtnOk		PROTO	hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM
calcBtnMov	PROTO	hdlgMain:HWND, htxtRef:HWND
setTextArrA	PROTO	hWnd:HWND, pArrSz:PSZ, ndSz:ND, idStartSz:ID
setTextArrW	PROTO	hWnd:HWND, pArrWSz:PWSZ, ndWSz:ND, idStartWSz:ID
;
.DATA
szDlgTitle	CHAR	'Hello, Asm Unicode World!', 0
;
aszLang LABEL CHAR
szGreek		CHAR	'Greek:', 0
szItalian	CHAR	'Italian:', 0
szFrench	CHAR	'French:', 0
szSpanish	CHAR	'Spanish:', 0
szEnglish	CHAR	'English:', 0
szGerman	CHAR	'German:', 0
szHindi		CHAR	'Hindi:', 0
szArabian	CHAR	'Arabian:', 0
szHebrew	CHAR	'Hebrew:', 0
szChinese	CHAR	'Chinese:', 0
szJapanese	CHAR	'Japanese:', 0
szKorean	CHAR	'Korean:', 0
szVietnamese	CHAR	'Vietnamese:', 0
szMongolian	CHAR	'Mongolian:', 0
szTurkish	CHAR	'Turkish:', 0
szAzerbaijani	CHAR	'Azerbaijani:', 0
szUzbek		CHAR	'Uzbek:', 0
szKazakh	CHAR	'Kazakh:', 0
szTajik		CHAR	'Tajik:', 0
szFinnish	CHAR	'Finnish:', 0
szEstonian	CHAR	'Estonian:', 0
szArmenian	CHAR	'Armenian:', 0
szGeorgian	CHAR	'Georgian:', 0
szSerbian	CHAR	'Serbian:', 0
szBulgarian	CHAR	'Bulgarian:', 0
szCratian	CHAR	'Croatian:', 0
szCzech		CHAR	'Czech:', 0
szPolish	CHAR	'Polish:', 0
szUkrainian	CHAR	'Ukrainian:', 0
Belarusian	CHAR	'Belarusian:', 0
szRussian	CHAR	'Russian:', 0
;
	ALIGN	WCHAR
	.RADIX	16
awszHello LABEL WCHAR
wszGreek	WCHAR	"Γεια σου κόσμε!",0
wszItalian	WCHAR	"Ciao, mondo!",0
wszFrench	WCHAR	"Bonjour le monde!",0
wszSpanish	WCHAR	"Hola Mundo!",0
wszEnglish	WCHAR	"Hello, World!",0
wszGerman	WCHAR	"Hallo Welt!",0
wszHindi	WCHAR	"नमस्ते दुनिया!",0
wszArabian	WCHAR	"!مرحبا بالعالم",0
wszHebrew	WCHAR	"!שלום עולם",0
wszChinese	WCHAR	"你好,世界!",0
wszJapanese	WCHAR	"こんにちは世界!",0
wszKorean	WCHAR	"안녕, 세상!",0
wszVietnamese	WCHAR	"Xin Chào, Thế Giới!",0
wszMongolian	WCHAR	"Сайн байна уу, Дэлхийн!",0
wszTurkish	WCHAR	"Selam Dünya!",0
wszAzerbaijani	WCHAR	"Salam, Dünya!",0
wszUzbek	WCHAR	"Salom Dunyo!",0
wszKazakh	WCHAR	"Сәлем Әлем!",0
wszTajik	WCHAR	"Салом, ҶАҲОН!",0
wszFinnish	WCHAR	"Height maailma!",0
wszEstonian	WCHAR	"Tere, Maailm!",0
wszArmenian	WCHAR	"Բարեւ Աշխարհը!",0
wszGeorgian	WCHAR	"გამარჯობა მსოფლიო!",0
wszSerbian	WCHAR	"Здраво, Свет!",0
wszBulgarian	WCHAR	"Здравей, Свят!",0
wszCroatian	WCHAR	"Zdravo, svijete!",0
wszCzech	WCHAR	"Ahoj světe!",0
wszPolish	WCHAR	"Witaj, Świecie!",0
wszUkrainian	WCHAR	"Привіт, Світ!",0
wszBelarusian	WCHAR	"Прывітанне Сусвет!",0
wszRussian	WCHAR	"Дратути!",0
	.RADIX	10
;
.DATA?
sBtnMov		BTN_MOV		<>
hInstance	HINSTANCE	?
hdlgMain	HWND		?
hbtnOk		HWND		?
pprBtnOkSys	PCODE		?
;
.CODE
START:
	INVOKE GetModuleHandle, NULL
	MOV	hInstance, EAX
	INVOKE DialogBoxParamW, hInstance, MainDlgId, NULL, Addr prDlgMain, NULL
	INVOKE ExitProcess, EAX
;
prDlgMain PROC Uses EDI hwnd:HWND, umsg:UINT, wparam:WPARAM, lparam:LPARAM
	MOV	EAX, umsg
	MOV	ECX, LengthOf tblwm
	LEA	EDI, tblwm
	REPNE SCASD
	JNE	procwm
	ADD	EDI, SizeOf tblwm
	PUSH	exit			; For supported WM only
procwm:
	JMP	PCODE Ptr [EDI]
.DATA
	ALIGN	WM
tblwm	WM	WM_INITDIALOG, WM_TIMER, WM_COMMAND, WM_CLOSE
	PCODE	skip			; If WM not supported
pmou	PCODE	wminitdialog
ptim	PCODE	processed, wmcommand, wmclose
.CODE
wminitdialog:
	MovE	hdlgMain, EAX, hwnd
	INVOKE SendMessageA, hwnd, WM_SETTEXT, NULL, Addr szDlgTitle
	INVOKE LoadIcon, hInstance, MainIconId
	INVOKE SendMessage, hwnd, WM_SETICON, MainIconId, EAX
	INVOKE GetDlgItem, hwnd, OkBtnId
	MOV	hbtnOk, EAX
	INVOKE SetWindowLong, EAX, GWL_WNDPROC, Addr prBtnOk
	MOV	pprBtnOkSys, EAX
	INVOKE setTextArrA, hwnd, Addr aszLang, LangRowNum, StartTxtAId
	INVOKE setTextArrW, hwnd, Addr awszHello, LangRowNum, StartTxtWId
	INVOKE GetDlgItem, hwnd, GreekTxtAId
	INVOKE calcBtnMov, hwnd, EAX
	INVOKE SetTimer, hwnd, MovTimerId, MovTimerPer, NULL
	MOV	tblwm, WmMouseOverBtn	; Instead WM_INITDIALOG
	MOV	pmou, setleftmov
	STC
	RETN
;
wmclose:
	INVOKE KillTimer, hwnd, MovTimerId
	INVOKE EndDialog, hwnd, NULL
	STC
	RETN
;
wmcommand:
	CMP	wparam, (BN_CLICKED Shl 16) Or OkBtnId
	JNE	notprocessed
	INVOKE SendMessage, hwnd, WM_CLOSE, NULL, NULL
processed:
	STC				; CF = 1: processed
	RETN
notprocessed:
	CLC				; CF = 0: not processed
	RETN
;
; Mouse is over OK button: set motion handler on timer
setleftmov:
	LEA	EAX, movbtnleft
	JMP	mouoveroff
setrightmov:
	LEA	EAX, movbtnright
mouoveroff:
	MOV	ptim, EAX		; Set btn moving handler on timer
	MOV	pmou, processed		; Mouse over btn off
	STC
	RETN
;
; Button motion handlers
loadbtnmovstuff:
	LEA	EDX, sBtnMov
 ASSUME EDX: Ptr BTN_MOV
	MOV	EAX, [EDX].Xstep
	MOV	ECX, [EDX].Xcur
	RETN
movbtnleft:
	CALL	loadbtnmovstuff
	SUB	ECX, EAX		; Xcur = Xcur - Xstep
	MOV	EAX, [EDX].Xmin
	CMP	ECX, EAX
	JG	movbtn			; Xcur > Xmin
	MOV	ECX, EAX		; Xcur = Xmin
	LEA	EAX, setrightmov
	JMP	stopbtn
movbtnright:
	CALL	loadbtnmovstuff
	ADD	ECX, EAX		; Xcur = Xcur + Xstep
	MOV	EAX, [EDX].Xmax
	CMP	ECX, EAX
	JL	movbtn			; Xcur < Xmin
	MOV	ECX, EAX		; Xcur = Xmax
	LEA	EAX, setleftmov
stopbtn:
	MOV	pmou, EAX		; Trigger on mouse over btn
	MOV	ptim, processed		; Timer off
movbtn:
	MOV	[EDX].Xcur, ECX
	INVOKE MoveWindow, hbtnOk, [EDX].Xcur, [EDX].Y, \
		[EDX].Width_, [EDX].Height, TRUE
 ASSUME EDX: Nothing
	STC
	RETN
;
skip:
	CLC
exit:
	MOV	EAX, 0
	ADC	EAX, EAX		; Set to FALSE or TRUE accord. CF
	RET
prDlgMain ENDP
;
prBtnOk PROC hwnd:HWND, umsg:UINT, wparam:WPARAM, lparam:LPARAM
	CMP	umsg, WM_MOUSEMOVE
	JNE	sysproc
	INVOKE PostMessage, hdlgMain, WmMouseOverBtn, wparam, lparam
sysproc:
	LEAVE
	JMP	[pprBtnOkSys]
prBtnOk ENDP
;
calcBtnMov PROC Uses EBX EDI hdlgm:HWND, htxtref:HWND
LOCAL srctxt: RECT
LOCAL srcbtnok: RECT
	LEA	EBX, srcbtnok
 ASSUME EBX: Ptr RECT
	INVOKE GetWindowRect, hbtnOk, EBX
	INVOKE MapWindowPoints, HWND_DESKTOP, hdlgm, EBX, SizeOf RECT/SizeOf POINT
	INVOKE GetWindowRect, htxtref, Addr srctxt
	INVOKE MapWindowPoints, HWND_DESKTOP, hdlgm, Addr srctxt, SizeOf RECT/SizeOf POINT
	LEA	EDI, sBtnMov
 ASSUME EDI: Ptr BTN_MOV
; MoveWindow requires height & width of window instead of bottom & right coords
	MovE	[EDI].Y, EDX, [EBX].top
	MOV	EAX, [EBX].bottom
	SUB	EAX, EDX			; Button Height
	MOV	[EDI].Height, EAX
	MovE	[EDI].Xmin, EDX, srctxt.left
	MovE	[EDI].Xmax, EAX, [EBX].left
	MOV	[EDI].Xcur, EAX			; Current X coord.
	MOV	ECX, [EBX].right
	SUB	ECX, EAX			; Button width
	MOV	[EDI].Width_, ECX
	SUB	EAX, EDX			; Button Xpath = Xmax - Xmin
	XOR	EDX, EDX
	MOV	ECX, BtnStepNum
	DIV	ECX				; Xstep= Xpath / XstepNum
	MOV	[EDI].Xstep, EAX		; Pixels per step
 ASSUME EBX: Nothing, EDI: Nothing
	RET
calcBtnMov ENDP
;
setTextArrA PROC hwnd:HWND, pasz:PSZ, nsz:ND, isz:ID
sendloop:
	INVOKE SendDlgItemMessageA, hwnd, isz, WM_SETTEXT, NULL, pasz
	DEC	nsz
	JZ	exit
	INC	isz
	INVOKE lstrlenA, pasz
	INC	EAX			; Skip 0
	ADD	pasz, EAX		; Next string
	JMP	sendloop
exit:
	RET
setTextArrA ENDP
;
setTextArrW PROC hwnd:HWND, pawsz:PWSZ, nwsz:ND, iwsz:ID
sendloop:
	INVOKE SendDlgItemMessageW, hwnd, iwsz, WM_SETTEXT, NULL, pawsz
	DEC	nwsz
	JZ	exit
	INC	iwsz
	INVOKE lstrlenW, pawsz
	INC	EAX			; Skip 0
	ADD	EAX, EAX		; Words->Bytes
	ADD	pawsz, EAX		; Next string
	JMP	sendloop
exit:
	RET
setTextArrW ENDP
;
END START
;

Screenshot notarized by SkyNet and executable are attached.

https://i109.fastpic.ru/big/2019/0504/79/2e5d53614ab55aa07bcba792c0be1b79.png

Attached files:
FileSizeUploadedDownloadsMD5 hash
HelloUcW.exe10240 bytes04.05.2019497a85332cff5c518b25bcf45733f267fe0
#15847 (ツ) johnfound
Created 05.05.2019, read: 4774 times

Using UTF-16 is not a good idea IMHO. In fact, there are two more or less reasonable alternatives: UTF-8 is you want to be small and ANSI compatible and UTF-32 if you want to be fast. FreshLib uses UTF-8.

#15848 (ツ) KyberMax
Last edited: 05.05.2019 by KyberMax, read: 4770 times
johnfound

Using UTF-16 is not a good idea IMHO.

Unfortunately, Micro$oft did not ask your HO and made this encoding as Unicode in Windows. However, as you might see, I use UCS-2 encoding in this program, not UTF-16, i.e. without surrogates, otherwise setTextArrW would look a bit more complicated.

johnfound

FreshLib uses UTF-8.

I know. That is why I use batch file instead of any IDE, because they are convenient and very easy to modify for anything. For example, I used this batch file as IDE when developing that program:

@echo off

set PROJ=HelloUcW
call Settings.bat

:LOOP
@echo    Project: %PROJ%
@echo [A]ssemble  [R]un  [D]elTrash  [L]ist:%LST%  [Q]uit
@choice /C:ARDLQ /N >nul
if errorlevel 5 goto QUIT
if errorlevel 4 goto SWLIST
if errorlevel 3 goto DELTR
if errorlevel 2 goto RUN

\Masm32\bin\nmake.exe /f %PROJ%.mak
goto LOOP

:RUN
%PROJ%
goto LOOP

:DELTR
call DelTrash.bat
goto LOOP

:SWLIST
if %LST%==Y goto LISTOFF
set LST=Y
goto SAVEVARS
:LISTOFF
call DelLists.bat
set LST=N

:SAVEVARS
@echo : Settings for MakeIt.bat>Settings.bat
@echo set LST=%LST%>>Settings.bat
goto LOOP

:QUIT
#15849 (ツ) johnfound
Created 05.05.2019, read: 4768 times
KyberMax

Unfortunately, Microsoft did not ask your HO and made this encoding as Unicode in Windows.

Because M$ never asked my HO, now I am using only Linux. :-D

#15851 (ツ) KyberMax
Last edited: 06.05.2019 by KyberMax, read: 4762 times
johnfound

...now I am using only Linux. :-D

Well, since you're writing in Asm under Linux, then why don't you translate Fresh to UTF-16 to bring the resentment of red-eyed penguins to the limit? In addition, this encoding is almost entirely fixed-width characters (excluding the 2K range), which will be a small but pleasant bonus to the basic motivation.

#15856 (ツ) johnfound
Created 06.05.2019, read: 4756 times
KyberMax

this encoding is almost entirely fixed-width characters

Well, "almost" is not enough. If I need fixed-width encoding, I will use UTF-32. But for now, I am considering the small size and ANSI compatibility more important, so I am using UTF-8. It is really not so hard for processing and the variable width is a performance problem very rarely.

On the other hand UTF-16 is the most inconvenient way to encode UNICODE. Why I should use it if I am not forced by the OS API?

#15857 (ツ) KyberMax
Created 07.05.2019, read: 4747 times
johnfound

Well, "almost" is not enough. If I need fixed-width encoding, I will use UTF-32.

Well, emoticons and Egyptian hieroglyphs can be ignored before the introduction of UTF-32 IMHO.

johnfound

Why I should use it if I am not forced by the OS API?

I would definitely use this encoding precisely because it is about the same as using Asm in Linux.

johnfound

I am considering the small size and ANSI compatibility more important, so I am using UTF-8.

Actually, I slightly exaggerated the possibilities of MASM (you initially knew about this, of course). MASM, of course, does not support Unicode - I just use a converter.

But as a result, there was an interesting opportunity to use Unicode and ASCII encoding simultaneously. In general, with this converter any, even the most ancient mammoth shit, can work with Unicode (now UCS-2). The only requirement: Asm should understand the text in single quotes as strings (strings in double quotes are translated by converter into hex words).

#15860 (ツ) KyberMax
Created 08.05.2019, read: 4740 times

Today I checked the ability to display surrogate pairs and found that the setTxtArrW procedure works correctly, because lstrlenW considers surrogate pairs as two words, not one character. So UTF-16 is supported.

Another thing is that even on Windows 7 x64 Unicode font in the field of surrogate pairs I did not find any characters at all.

#15867 (ツ) KyberMax
Last edited: 16.05.2019 by KyberMax, read: 4725 times

In addition to the previous post: it is interesting that the ranges of the first and second surrogates do not match. Therefore, it is possible to make an incorrect pair and then this pair will be displayed as two non-printable characters (as two squares). If the pair is made correctly, then it is displayed as one square (no symbols were found in the surrogate range). That is, the developers have narrowed the maximum possible range of 4 million to 1 million characters.

If someone gave the alphabet to the Chinese, Koreans and Japanese before the introduction of Unicode, then UTF-16 would be enough without any surrogates.

By the way, about the missed opportunities: are you still a fasm programmer, not nasm one?

#15868 (ツ) johnfound
Created 17.05.2019, read: 4724 times
KyberMax

By the way, about the missed opportunities: are you still a fasm programmer, not nasm one?

Yes, I am. Every compiler must be self hosted. Or there is no reason to use it. If even its authors preferred not to use it... ;-)

#15869 (ツ) KyberMax
Created 17.05.2019, read: 4719 times
johnfound

Yes, I am

Well, actually I tried to change something in the past, but apparently something went wrong, sorry.

#15872 (ツ) KyberMax
Last edited: 29.05.2019 by KyberMax, read: 4687 times

I don’t know if you could compile the file without all the project files, but I didn’t publish the whole project, because I have long wanted to slightly expand the capabilities of the converter and used this opportunity to return to the development. As a goal, I chose one of the most monstrous assemblers - Atmel Avrasm, just look at its C-like syntax

As in C, strings in this asm can only be in double quotes, and characters only in single quotes. So I had to enter the key to convert single quotes into double quotes.

Source:

;
.NOLIST
.INCLUDE 'm48def.inc'
.LIST
.LISTMAC
;
.EQU CR		= $D
.EQU LF		= $A
.EQU DQ		= $22
;
.MACRO LdiW
	LDI	@1, Low (@2)
	LDI	@0, High (@2)
.ENDMACRO
;
.ESEG
ewszDblQuo:	.DW	"Это ""UTF-16"" строка", 0
eszDblQuo:	.DB	'This is ', """", 'ASCII', """",' string with dbl.quot.marks', CR, LF, 0
eszDQ:		.DB	'This is ', DQ, 'ASCII', DQ, ' string with DQ EQU', CR, LF, 0
;
.CSEG
START:
	LDI	R17, "U"
	LdiW	XH, XL, "Ж"
D_LOOP:
	RJMP	D_LOOP
;
cwszDblQuo:	.DW	"Это ""UTF-16"" строка", 0
cszDblQuo:	.DB	'This is ', """", 'ASCII', """",' string with dbl.quot.marks', CR, LF, 0
cszDQ:		.DB	'This is ', DQ, 'ASCII', DQ, ' string with DQ EQU', CR, LF, 0
;
.EXIT
;

The result of the converter:

;
.NOLIST
.INCLUDE "m48def.inc"
.LIST
.LISTMAC
;
.EQU CR		= $D
.EQU LF		= $A
.EQU DQ		= $22
;
.MACRO LdiW
	LDI	@1, Low (@2)
	LDI	@0, High (@2)
.ENDMACRO
;
.ESEG
ewszDblQuo:	.DW	$42D,$442,$43E,$20,$22,$55,$54,$46,$2D,$31,$36,$22,$20,$441,$442,$440,$43E,$43A,$430, 0
eszDblQuo:	.DB	"This is ", $22, "ASCII", $22," string with dbl.quot.marks", CR, LF, 0
eszDQ:		.DB	"This is ", DQ, "ASCII", DQ, " string with DQ EQU", CR, LF, 0
;
.CSEG
START:
	LDI	R17, $55
	LdiW	XH, XL, $416
D_LOOP:
	RJMP	D_LOOP
;
cwszDblQuo:	.DW	$42D,$442,$43E,$20,$22,$55,$54,$46,$2D,$31,$36,$22,$20,$441,$442,$440,$43E,$43A,$430, 0
cszDblQuo:	.DB	"This is ", $22, "ASCII", $22," string with dbl.quot.marks", CR, LF, 0
cszDQ:		.DB	"This is ", DQ, "ASCII", DQ, " string with DQ EQU", CR, LF, 0
;
.EXIT
;

Among other things, the example demonstrates how to place double quotes in strings (neither the Asm- nor the C-syntax is supported by this assembler). Hexadecimal numbers are defined in it using the prefixes 0x or $, so I had to enter the prefix definition key. In addition, fixed a bug that did not allow to specify any extension of the output file.

By the way, I had to modify the batch file to build the executable, because in the modern Masm32 package, there is no h2inc.exe utility, so you have to search it on the web or use h2incX.exe, developed by Japheth, instead. It can be downloaded from the developers site of a very cool Uasm assembler, the possibility of choosing which for assembly I also included in this batch file.

And of course in the Masm32 package there is no converter itself - this brilliant crutch, when meeting with the incredible capabilities of which the whistle of the great Australian humanist burnt so much that all his professionalism instantly fell off of him and he began bravely to spit shit in the back of the cyborg.

They said "a clever man"... However, sometimes people say strange things.

The complete packages for compiling examples consecrated by SkyNet are attached.

Upd: The converter is packaged separately and the M$ h2inc.exe utility package has been added.

Attached files:
FileSizeUploadedDownloadsMD5 hash
H2INC.7z89572 bytes29.05.2019381aa284974710e92ece8f7f9c87abcd8d5
HelloUcW.7z7851 bytes29.05.201937869eba57a0cb1b120baa99366b08f276b
Uasm2asm.7z3545 bytes29.05.2019379d7a128061702bd5a2f248cea2c537475
UniAvr.7z1255 bytes29.05.20193863b24342f2a78d18d68a45b23739eb24f
#15873 (ツ) johnfound
Last edited: 29.05.2019 by johnfound, read: 4681 times
KyberMax

just look at its C-like syntax

Well, I can't see C-likeness in the avrasm syntax. BTW, I am using AVRA which is (almost) compatible:

AVRA: advanced AVR macro assembler Version 1.3.0 Build 1 (8 May 2010)
Copyright (C) 1998-2010. Check out README file for more info

   AVRA is an open source assembler for Atmel AVR microcontroller family
   It can be used as a replacement of 'AVRASM32.EXE' the original assembler
   shipped with AVR Studio. We do not guarantee full compatibility for avra.

   AVRA comes with NO WARRANTY, to the extent permitted by law.
   You may redistribute copies of avra under the terms
   of the GNU General Public License.
   For more information about these matters, see the files named COPYING.
#15874 (ツ) KyberMax
Last edited: 31.05.2019 by KyberMax, read: 4675 times
johnfound

Well, I can't see C-likeness in the avrasm syntax

Description of strings and single characters: strings in double quotes only, single characters in single quotes only. In assembler free use of quotes.

C-style escape sequences \n \r, etc.

Using the prefixes 0x 0b instead of the suffixes h b.

Ability to use C-style comments.

C-style operators !~ << >> || == != etc.

johnfound

...I am using AVRA which is (almost) compatible

Yes, I know this assembler and in my development there is an opportunity to quickly change the assembler. The main difference is that Avrasm uses a 64-bit internal representation of variables, and avra uses 32-bit and it is easier to get overflow in calculations (apparently, therefore, avra has no .DQ directive). But avra has more advanced macros (in the C-style, by the way).

Perhaps yesterday it made sense to place here not only the result of the converter, but also the listing (after all, the chips are outdated and not everyone has these assemblers).

So, Unicode on Atmel AVR microcontrollers... How do you like this, Elon Musk?

AVRASM ver. 2.0.28  UniAvr._as Thu May 32 02:08:14 2019

UniAvr._as(3): Including file '\AVR\INC\m48def.inc'
                 
                 .LIST
                 .LISTMAC
                 ;
                 .EQU CR		= $D
                 .EQU LF		= $A
                 ;
                 .MACRO LdiW
                 	LDI	@1, Low (@2)
                 	LDI	@0, High (@2)
                 .ENDMACRO
                 ;
                 .CSEG
                 START:
000000 e515      	LDI	R17, $55
                +.MACRO LdiW
000001 e1a6     +	LDI	XL, Low ($416)
000002 e0b4     +	LDI	XH, High ($416)
                 	LdiW	XH, XL, $416
                 D_LOOP:
000003 cfff      	RJMP	D_LOOP
                 ;
000004 042d
000005 0442
000006 043e
000007 0020
000008 0022
000009 0055
00000a 0054
00000b 0046
00000c 002d
00000d 0031
00000e 0036
00000f 0022
000010 0020
000011 0441
000012 0442
000013 0440
000014 043e
000015 043a
000016 0430
000017 0000      cwszDblQuo:	.DW	$42D,$442,$43E,$20,$22,$55,$54,$46,$2D,$31,$36,$22,$20,$441,$442,$440,$43E,$43A,$430, 0
000018 6854
000019 7369
00001a 6920
00001b 2073
00001c 4122
00001d 4353
00001e 4949
00001f 2022
000020 7473
000021 6972
000022 676e
000023 0a0d
UniAvr._as(23): warning: .cseg .db misalignment - padding zero byte
000024 0000      cszDblQuo:	.DB	"This is ", $22, "ASCII", $22," string", CR, LF, 0
                 ;
...
Assembly complete, 0 errors, 1 warnings

EEPROM section and some strings are removed from the source and the listing for compactness.

#15876 (ツ) KyberMax
Created 03.06.2019, read: 4645 times

And that is not all.

So you say: "why does this cyborg use UTF-16 when everything works with UTF-8?". Well, you do not say it - you think. So I decided to check how well it works, and here is the result:

https://i106.fastpic.ru/big/2019/0603/0f/7fd2cbe142ca9d10229cb015394f270f.png

For the test, the simplest UTF-8 string was used, consisting of alternating consecutive Latin characters and one Chinese hieroglyph (to make it easier to orientate). On the right side of the picture, this string is displayed in the NotePad++ editor, and on the left in the Fresh IDE. The strings, starting with the second line, demonstrate consistent characters highlighting (the picture is maked with the Paint editor).

Yes of course, all this can be fixed, but this is a good example of the fact that simpler code is better because more reliable (and faster, by the way, which is important for microcontrollers). That is why I wrote this simple converter - so that I could use the true Unicode, and not bother with this crappy variable-length characters, this ugly crutch, invented by lazy C-developers. Ideally, they should have added the ability for the compiler to use the source code in Unicode UCS-2 (enter a special option for this), but instead they invented another type of Unicode. As a result, they facilitated the work of the compiler and turned the simplest programmer's work with strings into an intricate quest.

Test file attached.

Attached files:
FileSizeUploadedDownloadsMD5 hash
UniTest.asm18 bytes03.06.2019498af3e6fd5bc6d83c609b5c171ba287be8
#15877 (ツ) johnfound
Created 03.06.2019, read: 4642 times
KyberMax

And that is not all.

So you say: "why does this cyborg use UTF-16 when everything works with UTF-8?". Well, you do not say it - you think. So I decided to check how well it works, and here is the result:

https://i106.fastpic.ru/big/2019/0603/0f/7fd2cbe142ca9d10229cb015394f270f.png

For the test, the simplest UTF-8 string was used, consisting of alternating consecutive Latin characters and one Chinese hieroglyph (to make it easier to orientate). On the right side of the picture, this string is displayed in the NotePad++ editor, and on the left in the Fresh IDE. The strings, starting with the second line, demonstrate consistent characters highlighting (the picture is maked with the Paint editor).

Yes of course, all this can be fixed, but this is a good example of the fact that simpler code is better because more reliable (and faster, by the way, which is important for microcontrollers). That is why I wrote this simple converter - so that I could use the true Unicode, and not bother with this crappy variable-length characters, this ugly crutch, invented by lazy C-developers. Ideally, they should have added the ability for the compiler to use the source code in Unicode UCS-2 (enter a special option for this), but instead they invented another type of Unicode. As a result, they facilitated the work of the compiler and turned the simplest programmer's work with strings into an intricate quest.

Test file attached.

Well, I can't see any relation between Unicode encoding and the buggy display of the Chinese hieroglyphs in Fresh IDE. And a proof of this is that the Fresh IDE v2.x editor uses exactly UCS-2 encoding. Because it is Windows API implementation.

Fresh v3.x will use another editor that uses UTF-8. But I am not sure it will display the hieroglyphs properly, not because of the encoding, but simply because there is no monospaced fonts containing Chinese hieroglyphs.

So, the hieroglyphs you see in Notepad++ and Fresh IDE are from substitution font and the sizes of the characters are different. Fresh IDE editor always expect the width of the characters to be the same. You can see the same effect if set in the editor some proportional font. In this case even latin characters will be displayed wrong.

And in reverse - if you have a monospaced font containing the needed characters, everything will work ok.

#15878 (ツ) KyberMax
Last edited: 03.06.2019 by KyberMax, read: 4639 times

Yes, you're right - suddenly the thing is in different widths of characters. For verification, I even downloaded and installed the font of the last version of the Unifont. But even in it, the Chinese and other hieroglyphs have different widths, although it is declared as monospaced. You will have to take into account this feature for the correct display of all characters. Obviously, NotePad++ does not rely on the same width of characters when calculating the length of the string graphics; it sums the width of each character separately.

However, all this does not affect my opinion on UTF-8 encoding.

0 1 2

Error detected
0

AsmBB v3.0 (check-in: a316dab8b98d07d9); SQLite v3.42.0 (check-in: 831d0fb2836b71c9);
©2016..2023 John Found; Licensed under EUPL. Powered by Assembly language Created with Fresh IDE